Vivado Design Suite - Xilinx...Vivado Design Suite ユーザーガイド Tcl...

Vivado Design Suite ユーザーガイド

Tcl スクリプト機能の使用

UG894 (v2017.3) 2017 年 10 月 4 日

この資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資料によっては英語版の更新に対応していないものがあります。日本語版は参考用としてご使用の上、最新情報につきましては、必ず最新英語版をご参照ください。

UG894 (v2017.4) 2017 年 12 月 20 日

Tcl スクリプト機能の使用 2UG894 (v2017.3) 2017 年 10 月 4 日 japan.xilinx.com

改訂履歴

次の表に、この文書の改訂履歴を示します。

日付バージョン改訂内容

2017 年 10 月 4 日 2017.3 「タイミングパスオブジェクト」を追加。

「get_property およびリストの並べ替え」を追加。

2017 年 4 月 5 日 2017.1 Vivado Design Suite の新バージョン (2017.1) と Tcl Store GUI を反映して資料全体でスク

リーンショットをアップデート。

「外部プログラムの呼び出し」に Windows の例を追加。

「Tcl スクリプトの初期化」に情報を追加。

Vivado Design Suite スタートアップスクリプトの名前を Vivado_init.tcl に変更。

UG894 (v2017.4) 2017 年 12 月 20 日

2017/12/20: Vivado® Design Suite 2017.4 リリース。内容の変更なし。

https://japan.xilinx.com

https://japan.xilinx.com/about/feedback.html?docType=User_Guides&docId=UG894&Title=Vivado%20Design%20Suite%20%26%2312518%3B%26%2312540%3B%26%2312470%3B%26%2312540%3B%20%26%2312460%3B%26%2312452%3B%26%2312489%3B%3A%20Tcl%20%26%2312473%3B%26%2312463%3B%26%2312522%3B%26%2312503%3B%26%2312488%3B%26%2327231%3B%26%2333021%3B%26%2312398%3B%26%2320351%3B%26%2329992%3B&releaseVersion=2017.4&docPage=2

Tcl スクリプト機能の使用 3UG894 (v2017.3) 2017 年 10 月 4 日 japan.xilinx.com

目次

改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

第 1章: Vivado での Tcl スクリプト概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Tcl の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

ヘルプ情報の入手 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

プラットフォームによる Tcl 動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

コンパイルおよびレポート生成のスクリプト例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Tcl スクリプトの読み込みと実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Tcl スクリプトの記述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

デザインオブジェクトへのアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

オブジェクトのリストの処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

出力先の指定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

ループの制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

エラー処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

環境変数へのアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

外部プログラムの呼び出し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Vivado IDE (統合設計環境)/Tcl モード vs バッチモード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

カスタムデザインルールチェック (DRC) の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

ザイリンクス Tcl Store. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Tcl スクリプト記述のヒント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

付録 A: その他のリソースおよび法的通知ザイリンクスリソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

ソリューションセンター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Documentation Navigator およびデザインハブ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

トレーニングリソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

お読みください: 重要な法的通知 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

UG894 (v2017.4) 2017 年 12 月 20 日



第 1章

Vivado での Tcl スクリプト

概要

Tcl (ツールコマンド言語) は、さまざまなデザインツールおよびデザインデータにアクセスするための、変数、プ

ロシージャ (procs)、制御構造を含むインタープリター型プログラミング言語です。

ヒント : 詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 1] を参照するか、

「<command> -help」と入力してください。

Vivado® Design Suite の起動方法および使用方法の詳細は、『Vivado Design Suite ユーザーガイド : 入門』 (UG910) [参

照 2] を参照してください。

この言語は新しい関数呼び出しで簡単に拡張できるので、 1990 年代初期に開発されて以来、新しいツールやテクノ

ロジをサポートするため拡張されてきています。多くの EDA ベンダーが標準の API (アプリケーションプログラミ

ングインターフェイス) としてアプリケーションを制御および拡張するために導入しています。

ザイリンクスでは、 Vivado Design Suite のネイティブプログラミング言語として Tcl を導入しているので、この業界

標準言語に精通している設計者であれば簡単に取り入れ、理解できます。 Vivado Design Suite の Tcl インタープリ

ターは、アプリケーションの制御、デザインオブジェクトおよびプロパティへのアクセス、カスタムレポートの作

成を実行するための、 Tcl の機能と柔軟性を提供しています。 Tcl を使用すると、デザインの特定の要件に合わせて

デザインフローを変更できます。

Tcl には、ローカルファイルシステムのファイルに対して読み出しおよび書き込みを実行するビルトインコマンド

が含まれます。これにより、動的にディレクトリを作成し、 FPGA デザインプロジェクトを開始して、プロジェク

トにファイルを追加したり、合成およびインプリメンテーションを実行できます。デザインプロジェクトからデバ

イスリソースの使用率や QoR (結果の質) に関するカスタマイズレポートを生成し、企業内で共有できます。

また、 Tcl を使用して、新しい設計手法を試したり、既存の問題を回避したり、必要に応じてデザインオブジェクト

の挿入および削除、プロパティの変更を実行でき。デザインフローの確立された部分を再実行するためのスクリプ

トを記述し、プロセスを標準化できます。

このガイドで説明する Tcl コマンドおよびスクリプト例のほとんどは、 Vivado Design Suite 特定のものです。 Vivado

特定の Tcl コマンドの詳細は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 1] を参照する

か、または Vivado ツールのヘルプ機能を使用してください。

Vivado IDE では、ザイリンクスデザイン制約 (XDC) を使用してデザイン制約を指定します。 XDC は Vivado で使用

可能な Tcl コマンドのサブセットに基づいており、 Tcl と同様に解釈されます。 XDC コマンドには、主にタイミング

制約、物理制約、オブジェクトクエリ、およびいくつかの Tcl ビルトインコマンド (set、 list、および expr) が

あります。DSP 関数の詳細は、『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903) [参照 3] を参照してくださ

い。 Tcl スクリプトとは異なり、 XDC ファイルは Vivado IDE で管理されるので、グラフィカルインターフェイスで

の制約の変更は元の XDC ファイルに保存されます。そのため、 XDC ファイルでは XDC コマンドのみを使用できま

す。制約の記述にほかの Tcl コマンドを使用する必要がある場合は、 Tcl スクリプトを使用する必要があります。

Tcl スクリプト機能の使用 4UG894 (v2017.3) 2017 年 10 月 4 日 japan.xilinx.comUG894 (v2017.4) 2017 年 12 月 20 日



第 1 章: Vivado での Tcl スクリプト

Vivado ツールでは、 vivado.jou というジャーナルファイルが Vivado を起動したディレクトリに作成されます。

ジャーナルファイルにはセッション中に実行された Tcl コマンドが記録されるので、このファイルから新しい Tcl ス

クリプトを作成できます。

ログファイル (vivado.log) も作成され、実行されたコマンドの出力が含まれます。ジャーナルファイルとログ

ファイルは、実行されたコマンドおよびその結果を確認するのに有益です。

Vivado Design Suite にビルトインされている Tcl インタープリターにより、追加の Tcl コマンドが提供されています。

Tcl ビルトインコマンドについては、 Tcl のオープンソースベースおよび資料を管理している Tcl Developer Xchange

サイト [参照 8] を参照してください。

Tcl プログラミング言語の入門チュートリアルは、 http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html を参照してくださ

い。また、 Tclers ’Wiki (http://wiki.tcl.tk) にいくつかのサンプルスクリプトがあります。

このガイドでは、 Tcl コマンドおよび Tcl スクリプトの例、および Vivado Design Suite での戻り値を示します。これら

のコマンド例とその戻り値は、次の形式で記述されています。

• Tcl コマンドおよびスクリプト例

puts $outputDir

• Tcl コンソールへの出力または Tcl コマンドの結果

./Tutorial_Created_Data/cpu_output


http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html

http://wiki.tcl.tk




Tcl の概要

Tcl スクリプトは、改行またはセミコロンで区切られた一連の Tcl コマンドです。 Tcl コマンドは、スペースまたはタ

ブで区切られた単語の文字列です。 Tcl インタープリターはコマンドラインを単語に分割し、必要に応じてコマンド

および変数置換を実行します。コマンドラインは左から右に読み込まれ、各単語が完全に評価されてから次の単語

が評価されます。コマンドおよび変数置換は、左から右に実行されます。

単語は、 1 つの単語または中かっこ ({}) またはダブルクォーテーション (“”) で囲まれた複数の単語です。中かっこま

たはダブルクォーテーション内のセミコロン、中かっこ、タブ、スペース、改行は、通常の文字として処理されま

すが、バックスラッシュ (\) はこの後説明するように、中かっこまたはダブルクォーテーション内でも特殊文字とし

て処理されます。

初の単語はコマンドとして扱われ、その後の単語は引数としてコマンドに渡されます。

set outputDir ./Tutorial_Created_Data/cpu_output

この例では、初の単語は Tcl set コマンドで、値を割り当てるために使用します。 2 番目の単語は変数名

(outputDir)、 3 番目の単語は変数値 (./Tutorial_Created_Data/cpu_output) として set コマンドに渡され

ます。

単語にバックスラッシュ (\) が使用されている場合、 Tcl インタープリターによりバックスラッシュ置換が実行され

ます。ほとんどの場合、バックスラッシュの次の文字は標準文字として処理されます。これを使用して、ダブル

クォーテーション、中かっこ、ドル記号などの特殊文字を文字列に追加できます。 Tcl インタープリターでバックス

ラッシュ文字がどのように処理されるかは、 Tcl/Tk のリファレンスを参照してください。

puts $outputDir ./Tutorial_Created_Data/cpu_output puts \$outputDir $outputDir

中かっことダブルクォーテーションマークの使用法も異なります。中かっこ内の文字に対しては、置換は実行され

ません。中かっこ内の単語や文字列はそのまま処理され、変数またはコマンド置換のために評価されません。次の

例に示すように、単語は中かっこに囲まれたそのままの文字列 (中かっこは含まない) となります。ダブルクォー

テーションに囲まれた文字列は評価され、変数およびコマンド置換が必要に応じて実行されます。ダブルクォー

テーションに囲まれた文字列に対してコマンド置換、変数置換、およびバックスラッシュ置換が実行されます。

puts {The version of Vivado Design Suite is [version -short]}The version of Vivado Design Suite is [version -short]

puts "The version of Vivado Design Suite is [version -short]"The version of Vivado Design Suite is 2016.1

上記の例で、ダブルクォーテーションを使用した 2 番目の例では [version -short] コマンドが戻り値で置換され

ていますが、中かっこを使用した 1 番目の例では置換が実行されていないことに注目してください。文字列を囲む

場合には、このことに注意してダブルクォーテーションまたは中かっこを選択してください。

変数に値を代入するには、 set コマンドを使用します。変数を参照するには、変数名の前にドル記号 ($) を付けて指

定します。単語がドル記号で開始している場合、 Tcl インタープリターで変数置換が実行され、変数が現在その変数

に保存されている値に置換されます。 Tcl では、 $ は予約語です。

set outputDir ./Tutorial_Created_Data/cpu_outputputs $outputDir./Tutorial_Created_Data/cpu_output





角かっこ ([ ]) を使用すると、コマンド内にコマンドをネストできます。ネストされたコマンドは、左から右にボト

ムアップに評価されます。角かっこ内の文字列が新しい Tcl スクリプトとして反復的に処理されます。ネストされた

コマンドに、さらにコマンドをネストさせることもできます。ネストされたコマンドの結果がその上位のコマンド

に渡されてから、その上位のコマンドが処理されます。

set listCells [lsort [get_cells]]

上記の例では、現在のデザインの上位にあるセルオブジェクトがアルファベット順に並べ替えられ、そのリスト

が listCells 変数に代入されます。まず get_cells コマンドが実行され、返されたオブジェクトが lsort コマ

ンドで並べ替えられて、並べ替えが終了したリストが変数に代入されます。

ただし Vivado Design Suite では、角かっこの処理は標準の Tcl と多少異なります。角かっこは Verilog および VHDL の

名前 (ネット、インスタンスなど) では標準文字として処理され、通常はバスやインスタンスの配列など、ベクター

の 1 つまたは複数の要素を示します。 Vivado ツールでは、角かっこがネットリストオブジェクト名の一部である場

合はボトムアップに評価されません。

次の 3 つのコマンドは同等です。

1.) set list_of_pins [get_pins transformLoop[0].ct/xOutReg_reg/CARRYOUT[*] ]2.) set list_of_pins [get_pins {transformLoop[0].ct/xOutReg_reg/CARRYOUT[*] } ]3.) set list_of_pins [get_pins transformLoop\[0\].ct/xOutReg_reg/CARRYOUT\[*\] ]

1) では、外側の角かっこは標準の Tcl と同様にコマンドのネスト ([get_pins]) を表しますが、内側の角かっこは

Vivado ツールでは指定したオブジェクト名の一部として処理されます (transformLoop[0])。 Vivado Design Suite

ではこれが自動的に処理されますが、一部の文字に限られます。これらの文字は次のいずれかの形式にする必要が

あり、それ以外の場合は角かっこは標準の Tcl と同様に評価されます。

• star: [*]: 任意の数のビットまたはインスタンスを示すワイルドカードです。

• integer: [12]: 特定のビットまたはインスタンスを指定します。

2) では、中かっこを使用して内側の角かっこ内の文字列がコマンド置換されないようにしており、オブジェクト名

の一部として処理されます (transformLoop[0])。

3) では、バックスラッシュを使用して角かっこを特殊文字でなく標準文字として評価するよう指定しており、コマ

ンド置換は実行されません。

2) および 3) は角かっこが適切に処理されるようにする方法を示していますが、中かっこまたはバックスラッシュを

手動で追加する必要があります。 1) は、これが Vivado Design Suite で自動的に処理されることを示しています。

Tcl スクリプトにコメントを追加するには、行を # で開始します。 # の後に続く次の改行までの文字は、無視されま

す。行の後にコメントを追加するには、次の例に示すように、コマンドの後にセミコロン ( ; ) を記述し、その後

に # を追加してコメントを記述します。

# This is a commentputs "This is a command"; # followed by a comment

ヘルプ情報の入手

Tcl コンソールでヘルプ情報を取得できます。すべての Vivado コマンドで -help オプションがサポートされており、

コマンドラインの任意の位置で使用できます。

次に例を示します。





Vivado% create_clock -helpVivado% create_clock -name CLK1 -period 10 -help

また、 help コマンドを使用してもヘルプ情報を表示できます。 help コマンドでコマンド名を指定すると (help

<command>)、 <command> -help を使用した場合と同じ情報が表示されます。

Vivado% help create_clock

help コマンドで -args オプションを使用すると、引数の簡単な説明のみを表示できます。

Vivado% help create_clock -args

create_clock

Description: Create a clock object

Syntax: create_clock -period <arg> [-name <arg>] [-waveform <args>] [-add] [-quiet] [-verbose] [<objects>]

Returns: new clock object

Usage: Name Description ------------------------ -period Clock period: Value > 0 [-name] Clock name [-waveform] Clock edge specification [-add] Add to the existing clock in source_objects [-quiet] Ignore command errors [-verbose] Suspend message limits during command execution [<objects>] List of clock source ports, pins or nets

また、 -syntax オプションを使用すると、コマンド構文のみを表示できます。

Vivado% help create_clock -syntax

create_clock

Syntax: create_clock -period <arg> [-name <arg>] [-waveform <args>] [-add] [-quiet][-verbose] [<objects>]

help コマンドを使用すると、特定のコマンドのヘルプ情報だけでなく、コマンドのカテゴリおよびプロジェクトの

クラスに関する情報も表示できます。カテゴリのリストを取得するには、 help コマンドを引数またはオプションを

使用せずに実行します。次に、コマンドカテゴリの一部を示します。

Vivado% help

ChipScopeDRCFileIOFloorplanGUIControlIPFlowObjectPinPlanning





PowerProjectPropertyAndParameterReportSDCSimulationTclBuiltInTimingToolLaunchToolsXDC

各カテゴリのコマンドのリストを取得するには、 -category オプションを使用します。たとえば、次のコマンドを

実行すると、 Tools カテゴリのすべてのコマンドが表示されます。

Vivado% help -category tools

Topic Descriptionlink_design Open a netlist designlist_features List available features.load_features Load Tcl commands for a specified feature.opt_design Optimize the current netlist. This will perform the retarget,

propconst, and sweep optimizations by default.phys_opt_design Optimize the current placed netlist.place_design Automatically place ports and leaf-level instancesroute_design Route the current designsynth_design Synthesize a design using Vivado Synthesis and open that design

プラットフォームによる Tcl 動作

使用するプラットフォーム (32 ビットまたは 64 ビット ) によって、 Tcl の動作が異なる場合がまれにあります。これ

は Vivado ではなく Tcl に関連しています。

たとえば、大きな整数のリストを並べ替える場合、次のコマンドを使用することが考えられます。

vivado% lsort $list -integer

このコマンドは、スクリプトを 32 ビットマシンで実行しているか、 64 ビットマシンで実行しているかによって動

作が異なります。これは、 32 ビットプラットフォームと 64 ビットプラットフォームで整数のコード記述が異なる

からです。

win32, win64, lnx32: sizeof(int) is 4byteslnx64: sizeof(int) is 8bytes

この例の問題を回避するには、 lsort コマンドの -command オプションを使用し、並べ替えを実行するカスタムプ

ロシージャを使用するのが 1 つの方法です。





コンパイルおよびレポート生成のスクリプト例

非プロジェクトフローでのコンパイル

次に、非プロジェクトデザインフローを定義する Tcl スクリプトの例を示します。

このサンプルスクリプトでは reportCriticalPaths というカスタムコマンドが使用されており、 Vivado Design

Suite にカスタムコマンドやプロシージャを追加できることを示しています。 reportCriticalPaths の内容は、

「Tcl プロシージャの定義」を参照してください。

# STEP#1: define the output directory area.#set outputDir ./Tutorial_Created_Data/cpu_output file mkdir $outputDir## STEP#2: setup design sources and constraints#read_vhdl -library bftLib [ glob ./Sources/hdl/bftLib/*.vhdl ]read_vhdl ./Sources/hdl/bft.vhdlread_verilog [ glob ./Sources/hdl/*.v ]read_verilog [ glob ./Sources/hdl/mgt/*.v ]read_verilog [ glob ./Sources/hdl/or1200/*.v ]read_verilog [ glob ./Sources/hdl/usbf/*.v ]read_verilog [ glob ./Sources/hdl/wb_conmax/*.v ]read_xdc ./Sources/top_full.xdc## STEP#3: run synthesis, write design checkpoint, report timing, # and utilization estimates#synth_design -top top -part xc7k70tfbg676-2write_checkpoint -force $outputDir/post_synth.dcpreport_timing_summary -file $outputDir/post_synth_timing_summary.rptreport_utilization -file $outputDir/post_synth_util.rpt## Run custom script to report critical timing pathsreportCriticalPaths $outputDir/post_synth_critpath_report.csv## STEP#4: run logic optimization, placement and physical logic optimization, # write design checkpoint, report utilization and timing estimates#opt_designreportCriticalPaths $outputDir/post_opt_critpath_report.csvplace_designreport_clock_utilization -file $outputDir/clock_util.rpt## Optionally run optimization if there are timing violations after placementif {[get_property SLACK [get_timing_paths -max_paths 1 -nworst 1 -setup]] < 0} { puts "Found setup timing violations => running physical optimization" phys_opt_design}write_checkpoint -force $outputDir/post_place.dcpreport_utilization -file $outputDir/post_place_util.rptreport_timing_summary -file $outputDir/post_place_timing_summary.rpt## STEP#5: run the router, write the post-route design checkpoint, report the routing





# status, report timing, power, and DRC, and finally save the Verilog netlist.#route_designwrite_checkpoint -force $outputDir/post_route.dcpreport_route_status -file $outputDir/post_route_status.rptreport_timing_summary -file $outputDir/post_route_timing_summary.rptreport_power -file $outputDir/post_route_power.rptreport_drc -file $outputDir/post_imp_drc.rptwrite_verilog -force $outputDir/cpu_impl_netlist.v -mode timesim -sdf_anno true## STEP#6: generate a bitstream# write_bitstream -force $outputDir/cpu.bit

サンプルスクリプトの詳細

上記のサンプルスクリプトは、次の段階から構成されています。

• 手順 1: 変数 $outputDir を定義して出力ディレクトリを指定し、そのディレクトリを実際に作成します。

$outputDir 変数は、スクリプトで必要に応じて参照されます。

• 手順 2: デザインを記述する VHDL および Verilog ファイルと、デザインの物理制約およびタイミング制約を含

む XDC ファイルを読み込みます。合成済みネットリスト (EDIF または NGC) を読み込む場合は、 read_edif

コマンドを使用します。

Vivado Design Suite では、デザイン制約を使用してデザインの物理特性およびタイミング特性を定義します。

read_xdc コマンドは XDC 制約ファイルを読み込み、読み込まれた制約ファイルが合成およびインプリメン

テーションに適用されます。

重要: Vivado Design Suite では、 UCF フォーマットはサポートされません。 UCF 制約を XDC コマンドに移行する方法

は、『ISE から Vivado Design Suite への移行ガイド』 (UG911) [参照 4] を参照してください。

read_* Tcl コマンドは、非プロジェクトモードで使用し、 Vivado Design Suite でディスク上のファイルを読み

込んでメモリ内にデザインデータベースを構築します。ファイルがコピーされたり、プロジェクトモードでの

ようにファイルの依存関係が作成されることはありません。非プロジェクトモードでのすべての操作は、

Vivado ツール内のインメモリデータベースに対して実行されます。そのため、非プロジェクトモードは非常に

柔軟ですが、ユーザーがソースデザインファイルの変更を管理し、それに応じてデザインをアップデートする

必要があります。プロジェクトモードまたは非プロジェクトモードを使用した Vivado Design Suite の実行に関

する詳細は、『Vivado Design Suite ユーザーガイド : デザインフローの概要』 (UG892) [参照 5] を参照してくださ

い。

• 手順 3: デザインを指定のターゲットデバイス用に合成します。

HDL デザインファイルをコンパイルし、 XDC ファイルに含まれるタイミング制約を適用し、ロジックをザイリ

ンクスプリミティブにマップして、メモリ内にデザインデータベースを作成します。 Vivado ツールをバッチ

モードで実行している場合でも、 Tcl シェルモードで対話的に Tcl コマンドを実行している場合でも、グラフィ

カルモードでデザインデータを Vivado 統合設計環境 (IDE) で表示している場合でも、メモリ内のデザインは

Vivado ツール内に存在します。

合成が完了したら、チェックポイントを保存します。この時点では、デザインはタイミング制約および物理制

約が適用された未配置の合成済みネットリストです。タイミングやリソース使用率など、さまざまなレポート

を作成すると、デザインを理解するのに有益です。





このサンプルスクリプトでは、 reportCriticalPaths というカスタムコマンドを使用して、 TNS、 WNS、

違反を CSV ファイルにレポートします。これにより、クリティカルなパスをすばやく特定できます。

合成後に read_xdc または source コマンドを使用して読み込まれた XDC ファイルは、インプリメンテーショ

ンにのみ適用されます。それらのファイルは、その後デザインチェックポイントを保存した場合にネットリス

トと共に保存されます。

• 手順 4: 配置配線の準備としてロジック適化を実行します。適化の目的は、ターゲットパーツの物理リソー

スに配置する前にロジックデザインを簡略化することです。適化後、タイミングドリブン配置を実行しま

す。

各手順の後、 reportCriticalPaths コマンドを実行して新しい CSV ファイルを生成します。デザインの異

なる段階からの複数の CSV ファイルを使用すると、カスタムタイミングサマリスプレッドシートを作成でき、

インプリメンテーションの各段階でタイミングがどのように向上したかを理解するのに役立ちます。

配置が完了したら、 get_timing_paths コマンドを使用して配置済みデザインのワーストタイミングパスの

SLACK プロパティを取得します。 report_timing コマンドを使用すると、ワーストスラックを含むタイミン

グパスの詳細なテキスト形式レポートが生成されますが、 get_timing_paths コマンドを使用すると、同じ

タイミングパスが Tcl オブジェクトとして、パスの主なタイミング特性に対応するプロパティと共に返されま

す。 SLACK プロパティは指定したタイミングパス (この例の場合はワーストパス) のスラックを返します。ス

ラックが負の場合、物理適化を実行して、配置タイミング違反の解決を試みます。

手順 4 の後にチェックポイントを保存し、デザインのタイミングサマリとデバイス使用率をレポートします。

これにより、配線前と配線後のタイミングを比較し、配線のタイミングへの影響を評価できます。

• 手順 5: タイミングドリブン配線を実行し、チェックポイントを保存します。これでメモリ内のデザインが配線

されたので、追加のレポートを生成して、消費電力、デザインルール違反、終的なタイミングに関する重要

な情報を入手できます。レポートはファイルに出力しておいて後で確認できるほか、 Vivado IDE に表示してイ

ンタラクティブに確認することもできます。その後、タイミングシミュレーション用に Verilog ネットリストを

エクスポートします。

• 手順 6: デザインをザイリンクス FPGA にプログラムするビットストリームを生成します。

プロジェクトフローでのコンパイル

次に、プロジェクトフローでデザインを合成し、ビットストリーム生成までのインプリメンテーションを実行する

スクリプト例を示します。この例では、 Vivado インストールディレクトリにある CPU サンプルデザインを使用し

ています。

## STEP#1: define the output directory area.#set outputDir ./Tutorial_Created_Data/cpu_projectfile mkdir $outputDircreate_project project_cpu_project ./Tutorial_Created_Data/cpu_project \ -part xc7k70tfbg676-2 -force## STEP#2: setup design sources and constraints#add_files -fileset sim_1 ./Sources/hdl/cpu_tb.vadd_files [ glob ./Sources/hdl/bftLib/*.vhdl ]add_files ./Sources/hdl/bft.vhdladd_files [ glob ./Sources/hdl/*.v ]add_files [ glob ./Sources/hdl/mgt/*.v ]add_files [ glob ./Sources/hdl/or1200/*.v ]add_files [ glob ./Sources/hdl/usbf/*.v ]





add_files [ glob ./Sources/hdl/wb_conmax/*.v ]add_files -fileset constrs_1 ./Sources/top_full.xdcset_property library bftLib [ get_files [ glob ./Sources/hdl/bftLib/*.vhdl ]]## Physically import the files under project_cpu.srcs/sources_1/imports directoryimport_files -force -norecurse ## Physically import bft_full.xdc under project_cpu.srcs/constrs_1/imports directoryimport_files -fileset constrs_1 -force -norecurse ./Sources/top_full.xdc# Update compile order for the fileset 'sources_1'set_property top top [current_fileset]update_compile_order -fileset sources_1update_compile_order -fileset sim_1## STEP#3: run synthesis and the default utilization report.#launch_runs synth_1wait_on_run synth_1## STEP#4: run logic optimization, placement, physical logic optimization, route and# bitstream generation. Generates design checkpoints, utilization and timing# reports, plus custom reports.set_property STEPS.PHYS_OPT_DESIGN.IS_ENABLED true [get_runs impl_1]set_property STEPS.OPT_DESIGN.TCL.PRE [pwd]/pre_opt_design.tcl [get_runs impl_1]set_property STEPS.OPT_DESIGN.TCL.POST [pwd]/post_opt_design.tcl [get_runs impl_1]set_property STEPS.PLACE_DESIGN.TCL.POST [pwd]/post_place_design.tcl [get_runs impl_1]set_property STEPS.PHYS_OPT_DESIGN.TCL.POST [pwd]/post_phys_opt_design.tcl [get_runs impl_1]set_property STEPS.ROUTE_DESIGN.TCL.POST [pwd]/post_route_design.tcl [get_runs impl_1]launch_runs impl_1 -to_step write_bitstreamwait_on_run impl_1 puts "Implementation done!"

サンプルスクリプトの詳細

• 手順 1: create_project コマンドでプロジェクトを作成します。プロジェクトディレクトリおよびターゲッ

トデバイスが指定されています。指定したプロジェクトディレクトリが存在しない場合は、自動的に作成され

ます。

この例では、さまざまなレポートを保存する出力ディレクトリは、プロジェクトディレクトリと同じです。

• 手順 2: プロジェクトで使用されるすべてのファイルを宣言し、プロジェクトに追加します。これには、

add_files コマンドを使用します。ファイルをプロジェクトに追加すると、特定のファイルセットに追加され

ます。ファイルセットは、目的別にファイルをグループ化するコンテナーです。このスクリプト例では、ほと

んどのファイルはデフォルトのファイルセット (sources_1) に追加されますが、 Verilog テストテストベンチ

cpu_tb.v のみはデフォルトのシミュレーションファイルセット sim_1 に追加されます。

ファイルは、 import_files コマンドを使用してプロジェクトディレクトリにもコピーします。これにより、

プロジェクトでソースファイルのローカルコピーが使用され、元のソースファイルは参照されません。

• 手順 3: バックグランドで合成 run を起動し、デザインを合成します (launch_run synth_1)。 Vivado IDE によ

り必要なスクリプトがすべて自動的に生成され、別の Vivado セッションで合成が実行されます。合成 run は別

のプロセスで実行されるので、現在のスクリプトを続行する前に合成 run が完了するのを待つ必要があります。

これには、 wait_on_run コマンドを使用します。

合成 run が完了したら、 open_run synth_1 コマンドを使用して結果をメモリに読み込むことができます。制

約のないチェックポイントが、合成を実行したプロジェクトディレクトリに保存されます。この例では、

チェックポイントは次のディレクトリに保存されます。

./Tutorial_Created_Data/cpu_project/project_cpu.runs/synth_1/top.dcp





注記:合成 run のデフォルト名は synth_1、インプリメンテーション run のデフォルト名は impl_1 です。

create_run コマンドを使用して、追加の run を作成できます。

• 手順 4: launch_run コマンドを使用してインプリメンテーションを実行します。配置前の適化からビットス

トリーム生成までの完全な配置配線フローを、 1 つのコマンドで実行できます。このスクリプト例では、ビット

ストリーム生成までのインプリメンテーションが実行されます (launch_run impl_1 -to_step

write_bitstream)。

STEPS.PHYS_OPT_DESIGN.IS_ENABLED プロパティにより、オプションの phys_opt_design がイネーブルに

なっています。ユーザー定義の条件によりインプリメンテーションコマンドをダイナミックに呼び出すことができ

る非プロジェクトフローとは異なり、プロジェクトフローの run は実行する前に設定する必要があります。そのた

め、非プロジェクトフローの例とは異なり、この例では配置後のタイミングスラック値をチェックせずに物理ロ

ジック適化がイネーブルに設定されています。

run の Tcl フックプロパティ STEPS.<STEPNAME>.TCL.PRE および STEPS.<STEPNAME>.TCL.POST を使用する

と、各インプリメンテーション段階の前後にさまざまなレポートが生成できます。これらのプロパティを使用する

と、 run 構造を使用したときにフローで Tcl スクリプトをいつ実行するかを指定できます。詳細は、「Tcl フックスク

リプトの定義」を参照してください。

インプリメンテーション run は別の Vivado セッションで実行されるので、 Tcl 変数およびプロシージャをスクリプト

で使用するには、それらをそのセッションで初期化する必要があります。これには、いくつかの方法があります。

• 方法 1: Tcl 変数およびプロシージャを Vivado_init.tcl で定義します ( 「Tcl スクリプトの初期化」を参照)。

この方法で変数およびプロシージャを定義すると、すべてのプロジェクトおよびセッションに適用されます。

• 方法 2: 変数およびプロシージャを含む Tcl スクリプトを、 run で使用する制約セットに追加します。デザインを

メモリに読み込んだときに、制約の一部として読み込まれます。

• 方法 3: STEPS.OPT_DESIGN.TCL.PRE で変数およびプロシージャを含む Tcl スクリプトを設定します。このス

クリプトは、 OPT_DESIGN をイネーブルにした場合にのみ読み込まれます。デフォルトでは、 true に設定され

ています。

先ほど示したスクリプト例では、方法 3 を使用しています。変数およびプロシージャを含む Tcl スクリプトは、イン

プリメンテーション段階で次のように指定されています。

set_property STEPS.OPT_DESIGN.TCL.PRE [pwd]/pre_opt_design.tcl [get_runs impl_1]set_property STEPS.OPT_DESIGN.TCL.POST [pwd]/post_opt_design.tcl [get_runs impl_1]set_property STEPS.PLACE_DESIGN.TCL.POST [pwd]/post_place_design.tcl [get_runs impl_1]set_property STEPS.PHYS_OPT_DESIGN.TCL.POST [pwd]/post_phys_opt_design.tcl [get_runs impl_1]set_property STEPS.ROUTE_DESIGN.TCL.POST [pwd]/post_route_design.tcl [get_runs impl_1]

インプリメンテーション run は、コンパイル Tcl スクリプトが実行されるディレクトリとは異なるプロジェクトのサ

ブディレクトリで実行されるので、 Tcl スクリプトは絶対パスで指定する必要があります。

• pre_opt_design.tcl

############## pre_opt_design.tcl ##################set outputDir [file dirname [info script]]/Tutorial_Created_Data/cpu_projectsource [file dirname [info script]]/reportCriticalPaths.tcl#report_timing_summary -file $outputDir/post_synth_timing_summary.rptreport_utilization -file $outputDir/post_synth_util.rptreportCriticalPaths $outputDir/post_synth_critpath_report.csv

初の 2 行では、インプリメンテーション run の後の方のいくつかのスクリプトで使用される変数およびプロ

シージャを初期化します。次の 3 行では、タイミングレポートと使用率レポートを生成します。インプリメン

テーションのはじめにタイミング解析を実行し、配置配線で使用されるタイミング制約をチェックし、大きな





違反がないことを確認することが推奨されます。 reportCriticalPaths レポートは、デザインのワースト

パスに関する詳細を示します。この Tcl プロシージャについては、「Tcl プロシージャの定義」で詳細に説明しま

す。

• post_opt_design.tcl

############## post_opt_design.tcl ################### Run custom script to report critical timing pathsreportCriticalPaths $outputDir/post_opt_critpath_report.csv

outputDir 変数および reportCriticalPaths プロシージャは、同じ Vivado セッションの run で既に読み込

まれている pre_opt_design.tcl で定義されているので、このスクリプトでは定義する必要はありません。

opt_design の後にもタイミングレポートと使用率レポートを生成することが推奨されます。

• post_place_design.tcl

############## post_place_design.tcl ##################report_clock_utilization -file $outputDir/clock_util.rpt

配置後、クロックリソースの使用率およびデバイスでの位置を確認できます。フローの後の方では解決できな

い大きなタイミング違反を検出するため、タイミング解析を実行することが推奨されます。

• post_phys_opt_design.tcl

############## post_phys_opt_design.tcl ##################report_utilization -file $outputDir/post_phys_opt_util.rptreport_timing_summary -file $outputDir/post_phys_opt_timing_summary.rpt

配置後と同様、フローのこの段階でもタイミングレポートを確認することが重要です。

• post_route_design.tcl

############## post_route_design.tcl ##################report_route_status -file $outputDir/post_route_status.rptreport_timing_summary -file $outputDir/post_route_timing_summary.rptreport_power -file $outputDir/post_route_power.rptreport_drc -file $outputDir/post_imp_drc.rptwrite_verilog -force $outputDir/cpu_impl_netlist.v -mode timesim -sdf_anno true

配線後のタイミング解析では、配線済みの実際のネット遅延が使用されるので、タイミングのサインオフのた

め確認する必要があります。配線ステータスレポートには、配線問題の数が示されます。配線問題がある場合、

DRC レポートを生成するとそれらの問題を特定するのに役立ちます。

注記: フックスクリプトでインプリメンテーション段階を実行している場合、 Tcl 変数 ACTIVE_STEP を使用す

るとレポートのファイル名を固有にするなどを実行できます。変数 ACTIVE_STEP は、 run 構造の使用中 Vivado

により自動的にアップデートされます。詳細は、「段階間でのフックスクリプトの共有」を参照してください。

注記:上記のスクリプトで配線後に生成される Tcl レポートのほとんどは、 run でも自動的に生成されます。ま

た、プロジェクトフローを使用している場合は、フローの各段階の後にデザインチェックポイントも自動的に

生成されるので、スクリプトで write_checkpoint コマンドを呼び出す必要はありません。すべてのチェッ

クポイントとデフォルトのレポートは、インプリメンテーション run ディレクトリにあります。





./Tutorial_Created_Data/cpu_project/project_cpu.runs/impl_1/top_opt.dcptop_placed.dcptop_physopt.dcptop_routed.dcp

top_clock_utilization_placed.rpttop_control_sets_placed.rpttop_utilization_placed.rpttop_io_placed.rpttop_drc_routed.rpttop_power_routed.rpttop_route_status.rpttop_timing_summary_routed.rpt

インプリメンテーション run が完了したら、 open_run impl_1 コマンドを使用してインプリメント済みデザ

インをメモリに読み込むことができます。

Tcl スクリプトの読み込みと実行

Vivado Design Suite では、デザインセッション中に Tcl スクリプトを読み込んで実行するのに複数の方法があります。

ツールを起動したときにスクリプトファイルが自動的に読み込まれるようにするか、 Tcl コマンドラインで source

コマンドを使用して読み込むか、 Vivado IDE のメニューに追加します。

Tcl スクリプトの初期化

Vivado Design Suite で Tcl スクリプトが自動的に読み込まれるようにするには、 Vivado_init.tcl ファイルで定義

します。この方法は、新しいコマンドを定義する Tcl プロシージャを記述し、 Vivado のすべてのセッションで使用で

きるようにする場合に有益です。

注記: 2017.1 から、 Vivado Design Suite のスタートアップスクリプトの名前が Vivado_init.tcl に変更されていま

す。これまでのバージョンでは、 init.tcl という名前でした。 Vivado_init.tcl が存在せず init.tcl がある

場合は、 init.tcl が使用され、ファイルが古いことを示すメッセージが表示されます。

Vivado ツールを起動すると、 Tcl 初期化スクリプトが次の場所でリストされている順に検索されます。

1. ツールのインストールディレクトリ : <installdir>/Vivado/version/scripts/Vivado_init.tcl

<installdir> は Vivado Design Suite のインストールディレクトリです。

2. ローカルユーザーディレクトリ (Vivado ツールのバージョンによって異なる ):

° Windows 7: %APPDATA%/Xilinx/Vivado/<VivadoVersion>/Vivado_init.tcl

例: %APPDATA%/Xilinx/Vivado/2017.1/Vivado_init.tcl

° Linux: $HOME/.Xilinx/Vivado/<VivadoVersion>/Vivado_init.tcl

例: $HOME/.Xilinx/Vivado/2017.1/Vivado_init.tcl

3. ローカルユーザーディレクトリ (Vivado ツールのバージョンによって異なる ):

° Windows 7: %APPDATA%/Xilinx/Vivado/Vivado_init.tcl





° Linux: $HOME/.Xilinx/Vivado/Vivado_init.tcl

Vivado_init.tcl が複数の場所で見つかった場合は、上記の順序で読み込まれます。

インストールディレクトリにある Vivado_init.tcl ファイルを使用すると、企業またはデザイングループです

べてのユーザーに対して共通の初期化スクリプトをサポートできます。そのインストールディレクトリから Vivado

ツールを起動すると、共通の Vivado_init.tcl スクリプトが使用されます。

ホームディレクトリにある Vivado_init.tcl ファイルを使用すると、各ユーザーがそれぞれコマンドを追加した

り、デザイン要件を満たすためにツールのインストールディレクトリに含まれるコマンドを変更できます。

Vivado_init.tcl ファイルは標準の Tcl スクリプトファイルで、 Vivado ツールでサポートされるどの Tcl コマン

ドでも含めることができます。 source コマンドを追加して、 Vivado_init.tcl から別の Tcl スクリプトファイ

ルを読み込むこともできます。

注記: Vivado_init.tcl は <program>_init.tcl という命名規則に従っています。サポートされるほかのプログラム

名は、 xsim および vivado_lab です。たとえば、 Vivado シミュレータはスタートアップ時に xsim_init.tcl という

ファイルを検索します。

Tcl スクリプトの読み込み

source コマンドを使用すると、 Tcl スクリプトファイルを Vivado ツールに手動で読み込むことができます。

source <filename>

<filename> はファイル名とファイルの相対パスまたは絶対パスを指定します。パスをファイル名の一部として指

定しない場合は、現在の作業ディレクトリまたは Vivado Design Suite ツールを起動したディレクトリにファイルが作

成されます。

Vivado IDE で Tcl スクリプトを読み込むには、 [Tools] → [Run Tcl Script] をクリックします。

デフォルトでは、ファイルの各行が Tcl コンソールに表示されます。表示されないようにするには、 -notrace オプ

ションを使用します。これは、 Vivado Tcl インタープリターに特有のオプションです。

source <filename> -notrace

制約セットでの Tcl スクリプトの使用

Tcl スクリプトは、通常の XDC ファイルと同様に、プロジェクトの制約セットに追加できます。ただし、 XDC ファ

イルはツールで管理されますが、 Tcl スクリプトはツールで管理されません。 Tcl スクリプトで定義された制約が

ツールで変更されても、 Tcl スクリプトに自動的には保存されません。変更を保存するには、メモリの制約をすべて

ファイルにエクスポートし、このファイルを使用してスクリプトを手動でアップデートする必要があります。デザ

インをメモリで開くと (open_run)、 XDC ファイルの後に Tcl スクリプトが読み込まれます。これは、非プロジェク

トフローで read_xdc を使用して XDC ファイルを読み込んだ後に Tcl スクリプトを実行するのと同等です。制約

セットでの XDC ファイルおよび Tcl スクリプトの使用については、『Vivado Design Suite ユーザーガイド : 制約の使

用』 (UG903) [参照 3] を参照してください。

Tcl フックスクリプトの定義

非プロジェクトフローでは、 synth_design コマンド実行の前後など、フローのどの時点でも Tcl スクリプトを読

み込むことができます。プロジェクトベースフローでも、 Vivado IDE を使用するか、 set_property コマンドを使

用して合成 run またはインプリメンテーション run にプロパティを設定することにより、これを実行できます。 Tcl





フックスクリプトを使用すると、合成 run またはインプリメンテーション run、あるいはインプリメンテーションの

任意の段階の前 (tcl.pre) および後 (tcl.post) にカスタム Tcl スクリプトを実行できます。

合成 run またはインプリメンテーション run を起動すると、定義済みの Tcl スクリプトが使用され、選択したストラ

テジに基づいて標準デザインフローが処理されます。 Tcl フックスクリプトによりこの標準フローをカスタマイズ

できます。任意の段階で Tcl スクリプトを実行できるので、有益です。デザインフローの各段階の前後でフックス

クリプトを実行できます。一般的に、次のような使用法があります。

• カスタムレポート : タイミング、消費電力、リソース使用率、またはユーザー定義の Tcl レポート。

• フローの一部でのみタイミング制約を変更。

• ネットリスト、制約、またはデバイスプログラムを変更。

GUI では、デザイン run を右クリックして [Change Run Settings] をクリックすると、Tcl フックスクリプトを指定でき

ます。 [Design Runs] ウィンドウで run を右クリックして [Change Run Settings] をクリックし、 [Design Run Settings] ダ

イアログボックスを開きます。 [tcl.pre] および [tcl.post] オプションを使用して Tcl フックスクリプトを指定

します。

合成 run またはインプリメンテーション run にプロパティが設定され、 run の前 (tcl.pre) または後 (tcl.post) に

実行するスクリプトが指定されます (図 1)。 Tcl コンソールまたは Tcl スクリプトの一部として、合成 run またはイン

プリメンテーション run に直接このプロパティを設定することも可能です。

X-Ref Target - Figure 1

図 1: Tcl フックスクリプトの指定





合成 run に設定するプロパティは、次のとおりです。

STEPS.SYNTH_DESIGN.TCL.PRESTEPS.SYNTH_DESIGN.TCL.POST

たとえば、合成前に report.tcl スクリプトを実行するには、次のように設定します。

set_property STEPS.SYNTH_DESIGN.TCL.PRE {C:/Data/report.tcl} [get_runs synth_1]

インプリメンテーション run では、インプリメンテーションプロセスの各段階 ( 適化、消費電力適化、配置、配

置後の消費電力適化、物理適化、配線、ビットストリーム生成) の前後に Tcl スクリプトを実行できます。これ

らのプロパティは、次のとおりです。

STEPS.OPT_DESIGN.TCL.PRESTEPS.OPT_DESIGN.TCL.POSTSTEPS.POWER_OPT_DESIGN.TCL.PRESTEPS.POWER_OPT_DESIGN.TCL.POSTSTEPS.PLACE_DESIGN.TCL.PRESTEPS.PLACE_DESIGN.TCL.POSTSTEPS.POST_PLACE_POWER_OPT_DESIGN.TCL.PRESTEPS.POST_PLACE_POWER_OPT_DESIGN.TCL.POSTSTEPS.PHYS_OPT_DESIGN.TCL.PRESTEPS.PHYS_OPT_DESIGN.TCL.POSTSTEPS.ROUTE_DESIGN.TCL.PRESTEPS.ROUTE_DESIGN.TCL.POSTSTEPS.WRITE_BITSTREAM.TCL.PRESTEPS.WRITE_BITSTREAM.TCL.POST

重要: tcl.pre および tcl.post スクリプト内のパスは、プロジェクトの関連する run ディレクトリ

<project>/<project.runs>/<run_name> を基準とします。現在のプロジェクトまたは現在の run の

DIRECTORY プロパティを使用して、 Tcl フックスクリプト内の相対パスを定義できます。 get_property DIRECTORY [current_project]

get_property DIRECTORY [current_run]

段階間でのフックスクリプトの共有

フックスクリプトが段階に依存せず、インプリメンテーション段階の一連のレポートを生成するのみの場合、段階

ごとにスクリプトを複製して、そのインプリメンテーション段階に合わせてレポートファイル名のみを変更すると

いうのは効率がよくありません。すべてのインプリメンテーション段階でフックスクリプトを共有し、 Tcl 変数

ACTIVE_STEP を使用してレポートファイル名を構築する方法をお勧めします。この方法では、各段階に別のファ

イル名を付けることができます。

プロジェクトモードでは、 run 構造から run を実行するとき、実行するインプリメンテーション段階に合わせて Tcl

変数 ACTIVE_STEP が自動的にアップデートされます。

注記: Tcl 変数 ACTIVE_STEP は、プロジェクトモードで run 構造を使用するときのみ使用できます。

次に、 Tcl 変数 ACTIVE_STEP を使用したフックスクリプトの例を示します。

set step $ACTIVE_STEPreport_timing_summary -file tim_summary_${step}.rptif {$step == {route_design}} { report_route_status -file route_status.rpt}





GUI のカスタマイズ

[Tools] → [Custom Commands] → [Customize Commands] を使用して、 Vivado IDE のメインメニューおよびツールバー

にシステムまたはユーザー定義の Tcl コマンドを追加できます。メニューにカスタムコマンドを追加する方法の詳

細は、『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893) [参照 6] のこのセクションを参照してくださ

い。

Tcl スクリプトの記述

Tcl スクリプトを記述する際は、ユーザーの使いやすさに焦点を置く必要があります。つまり、ヘルプやインタラク

ティブコマンドライン引数を提供するなど、 Vivado に組み込まれているコマンドと同じように使用できるようにす

るのが理想的です。 get_* コマンドを使用した後に Vivado オブジェクトのが空かどうかなど、まれな状況もすべて

考慮する必要があります。 Tcl コードを記述する際は、コードで使用される下位プロシージャを作成するのも一般的

です。プロシージャとグローバル変数の名前の競合を回避するには、独自の名前空間内でコードを記述し、名前の

競合を小限に抑えるようにすることをお勧めします。

Tcl プロシージャの定義

Vivado Design Suite には、完全な Tcl インタープリターがビルトインされており、新しいカスタムコマンドやプロ

シージャを簡単に作成できます。 Tcl スクリプトを記述して Vivado IDE から読み込んで実行したり、プロシージャを

記述して、引数を取り、エラーをチェックして、結果を返す新しい Tcl コマンドとして使用できます。

Tcl プロシージャは proc コマンドで指定します。プロシージャ名、引数のリスト、実行するコードの本文を引数と

して指定します。次に、プロシージャ定義の簡単な例を示します。

proc helloProc { arg1 } {# This is a comment inside the body of the procedureputs "Hello World! Arg1 is $arg1"

}

ヒント : このプロシージャの定義では引数は 1 つなので中かっこで囲む必要はありませんが、中かっこを使用するこ

とでプロシージャ定義がわかりやすくなります。引数が複数ある場合は、中かっこは必須です。

通常プロシージャでは、定義済みの引数と、オプションでデフォルト値を指定します。引数にデフォルト値がある

場合、その前の必須の引数がすべて指定されていれば、プロシージャを呼び出したときにその引数を指定する必要

はありません。プロシージャは、 return コマンドを使用して値を返すよう指定していない場合、空のリストを返

します。

次の例では、 3 つの定義済み引数を持つ reportWorstViolations というプロシージャを定義しています。

proc reportWorstViolations { nbrPaths corner delayType } {report_timing -max_paths $nbrPaths -corner $corner -delay_type $delayType -nworst 1

}

プロシージャを実行する際、次の例に示すように、すべての引数を指定する必要があります。

%> reportWorstViolations 2 Slow max%> reportWorstViolations 10 Fast min


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug893-vivado-ide.pdf;a=xAddingCustomMenuCommands




次の例では、同じプロシージャで 3 つの引数のうち後の 2 つにデフォルト値があります。 corner のデフォルト値

は Slow、 delayType のデフォルト値は Max です。プロシージャの定義でデフォルト値が設定されているので、プ

ロシージャを呼び出す際は corner および delayType 引数の指定はオプションです。

proc reportWorstViolations { nbrPaths { corner Slow } { delayType Max } } {report_timing -max_paths $nbrPaths -corner $corner -delay_type $delayType -nworst 1

}

このプロシージャを実行する際は、次のすべての呼び出し方法が有効です。

%> reportWorstViolations 2%> reportWorstViolations 10 Fast%> reportWorstViolations 10 Slow Min

次のプロシージャの例には必須の引数 nbrPath がありますが、それ以外にも追加の引数を指定できます。この場

合、プロシージャを定義する際に引数のリストとして Tcl キーワード args を使用します。 args キーワードは、任

意の数の要素 (0 を含む) を含む Tcl リストを示します。

proc reportWorstViolations { nbrPaths args } {eval report_timing -max_paths $nbrPaths $args

}

Tcl コマンドを実行する際、 Tcl コマンドで使用可能なまたは必須のコマンドライン引数の代わりに変数置換を使用

できます。この場合、 Tcl eval コマンドを使用してコマンドの一部として Tcl 変数を含めたコマンドラインを評価

する必要があります。上記の例では、引数のリスト変数 ($args) が report_timing コマンドに変数として渡され

るので、 eval コマンドが必要です。

プロシージャを実行する際は、次のいずれの形式でも機能します。

%> reportWorstViolations 2%> reportWorstViolations 1 -to [get_ports]%> reportWorstViolations 10 -delay_type min_max -nworst 2

初の例では、値 2 が $nbrPaths 引数に渡され、 -max_paths に適用されます。 2 番目と 3 番目の例では、それぞ

れ 1 と 10 が -max_paths に適用され、その後の文字列は $args に代入されます。

次の例は、非プロジェクトモードのサンプルスクリプトで使用されていた reportCriticalPaths コマンドを示

します。このプロシージャでは 1 つの引数 $filename が使用され、コメントで各セクションを説明しています。

#------------------------------------------------------------------------# reportCriticalPaths#------------------------------------------------------------------------# This function generates a CSV file that provides a summary of the first# 50 violations for both Setup and Hold analysis. So a maximum number of # 100 paths are reported.#------------------------------------------------------------------------proc reportCriticalPaths { fileName } {# Open the specified output file in write modeset FH [open $fileName w]

# Write the current date and CSV format to a file headerputs $FH "#\n# File created on [clock format [clock seconds]]\n#\n"puts $FH "Startpoint,Endpoint,DelayType,Slack,#Levels,#LUTs"

# Iterate through both Min and Max delay typesforeach delayType {max min} {# Collect details from the 50 worst timing paths for the current analysis # (max = setup/recovery, min = hold/removal)





# The $path variable contains a Timing Path object.foreach path [get_timing_paths -delay_type $delayType -max_paths 50 -nworst 1] {# Get the LUT cells of the timing pathsset luts [get_cells -filter {REF_NAME =~ LUT*} -of_object $path]

# Get the startpoint of the Timing Path objectset startpoint [get_property STARTPOINT_PIN $path]# Get the endpoint of the Timing Path objectset endpoint [get_property ENDPOINT_PIN $path]# Get the slack on the Timing Path objectset slack [get_property SLACK $path]# Get the number of logic levels between startpoint and endpointset levels [get_property LOGIC_LEVELS $path]

# Save the collected path details to the CSV fileputs $FH "$startpoint,$endpoint,$delayType,$slack,$levels,[llength $luts]"

}}# Close the output fileclose $FHputs "CSV file $fileName has been created.\n"return 0

}; # End PROC





コマンドライン引数の解析

外部パラメーターまたは引数を使用するプロシージャを記述すると、プロシージャの使用範囲が広がり、無駄な

コードを記述する必要性を軽減できます。 1 つのプロシージャで複数のコンテキストを処理できるようにすると、重

複したコードを含む複数のプロシージャと同じ範囲のコンテキストを 1 つのプロシージャで網羅でき、使用および

管理が簡単になります。

これは、プロシージャをインタラクティブに使用する場合に特に有益です。一部のコマンドラインオプションをほ

かの Vivado コマンドと同じように指定できると、ユーザーにとって便利です。

Tcl では、これを args 変数を使用して簡単に適用できます。プロシージャの引数リスト内で使用される args キー

ワードは、任意の数の要素 (0 を含む) を示します。 args 変数は、ほかの Tcl リストと同様に処理および解析可能な

Tcl リストです。

コマンドライン引数を解析する方法は複数あります。次に、その 1 つの例を示します。

01 proc lshift listVar {02 upvar 1 $listVar L03 set r [lindex $L 0]04 set L [lreplace $L [set L 0] 0]05 return $r06 }07 08 09 proc myproc { args } {10 11 #-------------------------------------------------------12 # Process command line arguments13 #-------------------------------------------------------14 set error 015 set help 016 set verbose 017 set ports {}18 # if {[llength $args] == 0} { incr help }; # Uncomment if necessary19 while {[llength $args]} {20 set flag [lshift args]21 switch -exact -- $flag {22 -p -23 -ports {24 set ports [lshift args]25 }26 -v -27 -verbose {28 set verbose 129 }30 -h -31 -help {32 incr help33 }34 default {35 if {[string match "-*" $flag]} {36 puts " ERROR - option '$flag' is not a valid option."37 incr error38 } else {39 puts "ERROR - option '$flag' is not a valid option."40 incr error41 }





42 }43 }44 }45 46 if {$help} {47 set callerflag [lindex [info level [expr [info level] -1]] 0]48 # <-- HELP49 puts [format {50 Usage: %s51 [-ports|-p <listOfPorts>]52 [-verbose|-v]53 [-help|-h]54 55 Description: xxxxxxxxxxxxxxxxxxx.56 xxxxxxxxxxxxxxxxxxx.57 58 Example:59 %s -port xxxxxxxxxxxxxxx60 61 } $callerflag $callerflag ]62 # HELP -->63 return -code ok {}64 }65 66 # Check validity of arguments. Increment $error to generate an error67 68 if {$error} {69 return -code error {Oops, something is not correct}70 }71 72 # Do something73 74 return -code ok {}75 }

説明:

1. 行 1 ～ 6: リストの初の要素を削除するプロシージャ lshift を定義します。

2. 行 9: 複数の要素を指定可能な 1 つの引数 args を使用する myproc を定義します。このコード例では、myproc

は-ports <string>、 -verbose、 -help の 3 つのコマンドラインオプションをサポートします。

3. 行 19 ～ 44: すべてのコマンドライン引数をループします。すべての引数が処理されると、 args 変数は空にな

ります。

4. 行 20: 処理が必要なコマンドライン引数を flag 変数に保存します。 lshift プロシージャを使用して、 args

変数から引数を取得および削除します。

5. 行 21 ～ 43: flag 変数の内容を、有効なすべての引数に対してチェックします。 switch 文には -exact オプショ

ンが使用されており、 flag の内容が完全なオプション名に対してチェックされます。たとえば、ポートを定義

するには、 -p または -ports を指定する必要があります。

-p/-ports オプションではコマンドライン引数が指定され、 lshift args (行 24) により読み出され、削除され

ます。

-v/-verbose オプションはブール値で、 args からの引数は必要ありません (行 28)。

行 31 ～33: -h/-help オプションをチェックします。





行 36 ～38: 「-」で開始するすべてのコマンドライン引数をチェックします。このプロシージャ例では、サポー

トされません。

行 39 ～40: 「-」で開始しないすべてのコマンドライン引数をチェックします。このプロシージャ例では、サ

ポートされません。

6. 行 46 ～64:-h/-help が指定されている場合に、組み込まれているヘルプ情報を表示します。プロシージャにヘ

ルプ情報を組み込む必要がない場合は、これらの行と行 30 ～ 33 は削除できます。

7. 行 68 ～70:エラーが発生していないかをチェックします。通常、引数が有効であるかをチェックする追加コード

は、行 68 より前に記述する必要があります。指定されたコマンドラインオプションが互換していないなど、

エラーが発生している場合は、 error 変数がインクリメントされ、行 69 が実行されます。

8. 行 73 以降: コードを追加します。

上記のコードはコマンドライン引数を解析し、サポートされているオプションと完全に一致しているかを調べてい

ますが (行 21)、コマンドライン引数が完全に一致しているかを調べるよりも、条件式に一致しているかを調べる方

が有益な場合もあります。これには、行 21 で -exact オプションの代わりに -glob オプションを使用します。次

に例を示します。

21 switch -glob -- $flag {22 -p* -23 -ports {24 set ports [lshift args]25 }26 -v* -27 -verbose {28 set verbose 129 }30 -h* -31 -help {32 incr help33 }34 default {35 if {[string match "-*" $flag]} {36 puts " ERROR - option '$flag' is not a valid option."37 incr error38 } else {39 puts "ERROR - option '$flag' is not a valid option."40 incr error41 }42 }43 }

行 22、 26、および 30 では、ワイルドカードとしてアスタリスク (*) が使用されています。この場合、 -pfoo など、

-p で開始するすべての文字列が、ポートを定義する有効なコマンドラインオプションとなります。

上記のプロシージャ例 myproc はインタラクティブコマンドとして機能しますが、引数の解析のためランタイム

オーバーヘッドがあります。何回も呼び出される下位プロシージャでは、ランタイムオーバーヘッドが問題となる

ことがあります。プロシージャにコマンドライン引数を追加するのに別の方法を使用して、ランタイムオーバー

ヘッドを削減できます。これには、 Tcl 配列にコマンドライン引数のリストを割り当てます。ただし、各コマンド

ラインオプションに 1 つの引数しか使用できません。次に例を示します。

01 proc myproc2 { args } {02 # Default values03 set defaults [list -p 123 -v 0]04 # First, assign default values





05 array set options $defaults06 # Then, override with user choice07 array set options $args08 09 set ports $options(-p)10 set verbose $options(-v)11 set error 012 13 # Check validity of arguments. Increment $error to generate an error14 15 if {$error} {16 return -code error {Oops, something is not correct}17 }18 19 # Do something20 21 return -code ok {}22 }

説明:

1. 行 1: 複数の要素を指定可能な 1 つの引数 args を使用する myproc2 を定義します。args は後ほど Tcl 配列を設

定するのに使用されるので、引数の数は偶数にする必要があります。

2. 行 3: さまざまなオプションのデフォルト値を指定します。各オプションには、 1 つの引数のみ指定できます。

3. リストのフォーマットは、次のとおりです。

<option1> <valueForOption1> <option2> <valueForOption2> … <optionN> <valueForOptionN>

4. 行 5: Tcl 配列 options をデフォルト値で初期化します。

5. 行 7: args 変数の値でデフォルト値を置き換えます。

6. 行 9 ～ 10: 各オプションの値を $options(<option>) で読み出します。次のコードを使用して、オプションが

存在するかをチェックすることも可能です。

if [info exists options(<option>)] { … }

注記: フラグとして機能する値のないコマンドラインオプションは、 0 または 1 などの値を渡すことにより簡単にイ

ンプリメントできます。上記のプロシージャ例では、フラグ -v は「myproc2 -v 1」を使用してオンにできます。

ローカル変数とグローバル変数

プロシージャ内で作成された変数はローカルで、関数のスタック内で実行時に作成されます。ローカル変数はプロ

シージャ内でのみアクセス可能で、変数名がプロシージャ外の変数名と競合することはありません。たとえば、プ

ロシージャ内で作成されたローカル変数 foo とプロシージャ外で作成された foo とは別のもので、これらの変数に

はそれぞれ独立したコンテキストがあります。ローカル変数は、ほかの変数と同様に set Tcl キーワードで作成しま

す。

プロシージャの引数として定義されたパラメーターは、デフォルトでローカル変数となります。プロシージャが呼

び出されると (例: reportCriticalPaths $myfilename)、呼び出し変数 (例: $myfilename) はプロシージャの

スタック内にコピーされます。この場合、呼び出し変数が多数の要素を含む Tcl リストであると、ランタイムおよび

メモリ使用量が増加します。呼び出し変数の内容を変更することが必要な場合もあります。 Tcl では、変数の内容を

渡す代わりに、変数名を参照として渡す方法があります。変数が参照として渡されると、プロシージャ内での変数

の変更により、呼び出し空間内の呼び出し変数も直接変更されます。参照として渡すパラメーターを定義するには、

プロシージャの本文でキーワード upvar を使用します。前述の lshift ではこの手法を使用しています。

proc lshift {listVar} {





upvar 1 $listVar L set r [lindex $L 0] set L [lreplace $L [set L 0] 0] return $r }

サンプルプロシージャ myproc では、変数の内容 $args ではなく変数名 args を渡すことにより、 lshift を呼び

出しています。

グローバル変数は、プロシージャ外で作成された変数で、グローバル名前空間に属しています。プロシージャ内で

グローバル変数を参照するには、 global キーワードを使用し、その後に変数名を記述します。

proc printEnv {} { global env foreach var [lsort [array names env]] { puts " $var = $env($var)" }}

上記の例では、システム環境変数を表示する printEnv というプロシージャを定義しています。 Tcl 配列 env は、

Vivado ツールの起動時に初期化されるグローバル変数です。 printEnv プロシージャでは、 global env コマンド

を使用して env 変数を参照しています。グローバル変数を定義したら、ローカル変数と同様にアクセスできます。

グローバル変数は、読み出しおよび変更できます。

グローバル変数は、名前空間の修飾子を指定してアクセスすることもできます。グローバル名前空間の修飾子は

「::」なので、プロシージャでグローバル変数 env を参照するには「::env」を使用します。構文は、どのグロー

バル変数でも同じです。次に例を示します。

proc printEnv {} { foreach var [lsort [array names ::env]] { puts " $var = $::env($var)" }}

printEnv では env 変数への完全パスを指定しているので、 global env を宣言する必要はありません。

注記: グローバル変数はプロシージャの範囲外で作成された変数名に依存するので、グローバル変数の使用はお勧め

しません。プロシージャに大きな Tcl リストを渡す必要性を回避するため、グローバル変数が使用されることがあり

ます。グローバル変数を使用する前に、 upvar 手法を考慮してみてください。

注記: プロジェクトモードで run 基盤を使用する場合は、フックスクリプトを使用して Vivado 環境内で定義された

グローバル変数を共有することはできません。推奨されるスクリプト間での情報の共有方法については、「ユーザー

入力の取得」を参照してください。

注記: close_project および close_design コマンドでは、 Tcl インタープリターのステートは変更されません。

すべてのグローバル変数およびユーザーの作成した名前空間は、これらのコマンドを実行後にもそのまま保持され

ます。

プロシージャの名前空間

デフォルトでは、 Tcl インタープリター内で作成されたプロシージャはグローバル名前空間内に作成されます。この

欠点は、異なるソースからの複数の Tcl スクリプトが使用される場合に、プロシージャ名または変数名の競合が発生

する可能性があることです。また、一部のプロシージャのみで使用される、ユーザーが直接アクセスすることを意

図しないプロシージャが、グローバル名前空間に含まれることになる可能性もあります。

Tcl では、すべての変数およびプロシージャをグローバル名前空間内で定義する代わりに、範囲を制限した変数およ

びプロシージャを含む名前空間がサポートされています。名前空間はネストさせることができ、範囲のレベル数の

制限なしで、名前空間内に別の名前空間を定義できます。名前空間は、プロシージャ名および変数名に新しい構文

を追加します。 2 つのコロン (::) で、変数名またはプロシージャ名と名前空間名を区切ります。





次の例に、名前空間の作成方法とその名前空間にプロシージャおよび変数を割り当てる方法を示します。この例で

は、2 つのパブリックプロシージャ (push および pop) を含む小さなスタックの機能を再生する名前空間 foo を作成

しています。





01 namespace eval foo {02 variable stack [list]03 variable count 004 variable params05 array set params [list var1 value1 var2 value2 var3 value3]06 07 namespace export push pop08 09 proc push { args } {10 variable stack11 variable count12 lappend stack $args13 incr count14 }15 16 proc pop {} {17 variable stack18 variable count19 if {[llength $stack] > 0} {20 set value [lindex $stack end]21 set stack [lrange $stack 0 end-1]22 incr count -123 return $value24 } else {25 error " no more element in the stack"26 }27 }28 29 }30 31 proc foo::dump {} {32 variable stack33 variable count34 if {[llength $stack] > 0} {35 puts " There are $count element(s) in the stack:"36 foreach element $stack {37 puts " $element"38 }39 return 040 } else {41 error " no element in the stack"42 }43 }44 45 namespace import foo::*

説明:

1. 次のコマンドを使用して名前空間を定義します。

namespace eval <name> { … }

2. 行 1 は名前空間 foo を定義し、行 29 は名前空間定義の閉じかっこです。

3. 名前空間内の変数は、 variable コマンドで作成します (行 2 ～ 4)。

variable <varname> ?<varvalue>?

Tcl 配列を variable コマンドで初期化することはできません。まず作成し (行 4)、その後で初期化する必要が

あります (行 5)。





注記:名前空間内で変数を定義するのに set コマンドを使用しないでください。そのようにすると、グローバル

名前空間に同じ変数名がある場合に Tcl インタープリターで混同される可能性があります。

4. プロシージャは、名前空間定義の中または外に作成できます。コマンド namespace eval … { … } 内でプロ

シージャを作成した場合、名前に名前空間の修飾子 (この例では foo::) は必要ありません。

行 9 および 16: 名前空間定義内に push および pop を作成します。

5. プロシージャを名前空間定義外で作成し、プロシージャ名に完全な名前空間修飾子を付けて名前空間に追加す

ることもできます。上記の例では、プロシージャ dump を名前空間定義外で作成し、名前空間 foo に追加してい

ます (行 31)。

6. 行 10～11、 17～18、 32～33: プロシージャで、キーワード variable を使用して名前空間内で作成された変数

を参照します。

7. 名前空間内で作成されたプロシージャは、完全な名前空間修飾子 (foo::push、 foo::pop、 foo::dump など)

を使用してアクセスできます。同じ名前空間内のプロシージャを参照する場合は、名前空間修飾子は必要あり

ません。たとえば、 dump で push を呼び出す必要がある場合、 foo::push ではなく push を指定します。

8. 行 7: 名前空間では、パブリックおよびプライベートプロシージャという概念がサポートされます。名前空間内

のすべてのプロシージャは完全な名前空間修飾子を使用してアクセスできますが、コマンド namespace

export... を使用すると、どのプロシージャを名前空間外にエクスポートするかを指定できます。プロシー

ジャ名をエクスポートすると、コマンド namespace import... (行 45) を使用してグローバル名前空間にイン

ポートできます。このようにすると、プロシージャを完全な名前空間修飾子を指定せずに直接呼び出すことが

できるようになります。

次に、名前空間 foo の使用例を示します。

vivado% foo::push This is a test1vivado% foo::push {This is another line}2vivado% push This is the third line3vivado% foo::dump There are 3 element(s) in the stack: This is a test {This is another line} This is the third line0





vivado% puts "The last element stacked is: [foo::pop]"The last element stacked is: This is the third linevivado% puts "The previous element stacked is: [pop]"The previous element stacked is: {This is another line}vivado% foo::dump There are 1 element(s) in the stack: This is a test0vivado% dumpinvalid command name "dump"

テンプレートスクリプト

次に、先ほど説明した概念に基づくテンプレートスクリプトを示します。このスクリプトでは、次を示します。

1. プライベート名前空間を使用することにより、グローバル名前空間の汚染を回避 (lshift は名前空間 foo 内の

みで使用可能)。

2. コマンドライン引数の処理 (-help および -version でスクリプトのバージョンを示すなど)。

3. return -error (または error) コマンドを使用して必要に応じて Tcl エラーを生成。

namespace eval foo { namespace export myproc variable version 1.0}

proc foo::lshift listVar { upvar 1 $listVar L set r [lindex $L 0] set L [lreplace $L [set L 0] 0] return $r}

proc foo::myproc { args } {

#------------------------------------------------------- # Process command line arguments #------------------------------------------------------- set error 0 set help 0 set verbose 0 set ports {} # if {[llength $args] == 0} { incr help }; # Uncomment if necessary while {[llength $args]} { set flag [lshift args] switch -exact -- $flag { -p - -ports { set ports [lshift args] } -v - -verbose { set verbose 1 } -h - -help { incr help





} -version { variable version return $version } default { if {[string match "-*" $flag]} { puts " ERROR - option '$flag' is not a valid option." incr error } else { puts "ERROR - option '$flag' is not a valid option." incr error } } } }

if {$help} {set callerflag [lindex [info level [expr [info level] -1]] 0] # <-- HELP puts [format { Usage: %s [-ports|-p <listOfPorts>] [-verbose|-v] [-version] [-help|-h]

Description: xxxxxxxxxxxxxxxxxxx. xxxxxxxxxxxxxxxxxxx.

Example: %s -port xxxxxxxxxxxxxxx

} $callerflag $callerflag ] # HELP --> return -code ok {} }

# Check validity of arguments. Increment $error to generate an error

if {$error} { return -code error {Oops, something is not correct} }

# Do something

return -code ok {}}





デザインオブジェクトへのアクセス

Vivado Design Suite では、プロジェクト、デザイン、デバイス情報がインメモリデータベースに読み込まれ、合成、

インプリメンテーション、タイミング解析、およびビットストリームの生成に使用されます。このデータベースは、

プロジェクトモードでも非プロジェクトモードでも同じです。 FPGA デザインフローを実行していくと、それに応

じてデータベースがアップデートされます。デザインフローのどの段階でも、データベースの内容をチェックポイ

ントファイル (.dcp) に保存できます。 Vivado ツールで Tcl コマンドを使用すると、デザインデータベースにアクセ

スし、 Tcl オブジェクトをクエリしたり、プロパティを読み出しまたは設定したりして、その結果を Tcl スクリプト

でさまざまな目的で使用できます。データベースの内容を理解し、それに対してスクリプトをいかに効率的に記述

できるかを理解しておくと有益です。

Vivado Design Suite の Tcl インタープリターでは、プロジェクト、デバイス、ネット、セル、ピンなど、多数の

ファーストクラスオブジェクトにアクセスできます。 Vivado Design Suite では、プロジェクトモードでも非プロ

ジェクトモードでも、デザインの進行に応じてこれらのデザインオブジェクトが随時アップデートされ、インメモ

リデータベースに読み込まれます。

対話的にデザインオブジェクトのクエリ、プロジェクトの状態の解析、インメモリデザインにアクセスするスクリ

プトの記述、カスタムレポートの生成、オプションのデザインフロー手順などを実行できます。各オブジェクトに

は複数のプロパティがあり、いつでも読み出すことができ、また一部のプロパティは設定もできます。ほとんどの

デザインオブジェクトはほかのデザインオブジェクトに関連付けられており、その関連性をたどって関連オブジェ

クトやその情報を取得できます。

デザインオブジェクトのクエリには、 get_* Tcl コマンドを使用します。結果取得されたデザインオブジェクトは、

直接処理するか、 Tcl 変数に代入できます。 get_* コマンドをすべてリストするには、 help get_* を使用します。

オブジェクトを変数に代入すると、デザインデータベースに対するクエリの回数を削減でき、実行時間を短縮でき

ます。ネットやピンのリストのクエリは時間のかかるプロセスであり、結果を保存しておくことで、同じ情報に繰

り返しアクセスする必要がある場合にデザインフローを高速化できます。詳細は、「オブジェクトのキャッシュ」を

参照してください。

デザインオブジェクトの各クラス (ネット、ピン、ポートなど) には標準のプロパティがあり、読み出したり、一部

のプロパティは値を変更できます。また、 RTL ソースファイルで指定されているデザイン属性、 Verilog パラメー

ター、 VHDL ジェネリックも、それらが設定されているネットリストオブジェクトのプロパティとして保存されま

す。たとえば、ポートオブジェクトには方向を指定するプロパティがあり、ネットオブジェクトにはファンアウト

を指定するプロパティがあります。 Vivado ツールでは、これらのプロパティを追加、変更、およびレポートする多

数のコマンドがあります。 get_* -filter オプションを使用すると、デザインオブジェクトのリストにフィル

ターを適用し、特定のプロパティ値のオブジェクトのみを取得できます。詳細は、「フィルター結果」を参照してく

ださい。オブジェクトに設定されているプロパティのリストを取得するには、 list_property コマンドを使用し

ます。プロパティのタイプが enum である場合、 list_property_value コマンドを使用して有効な値のリストを

取得できます。

すべてのオブジェクトには、 NAME および CLASS プロパティがあります。オブジェクトを Tcl 変数に代入すると、

そのオブジェクトへのポインターが変数に保存されます。オブジェクトを変数により Tcl コマンドや Tcl プロシー

ジャに渡すことができます。オブジェクトが引数として文字列を必要とする Tcl プロシージャまたはコマンドに渡さ

れた場合、オブジェクトそのものではなくオブジェクトの NAME プロパティが渡されます。次の例に、セルオブ

ジェクトを変数 $inst に代入し、その変数に対して puts コマンドおよび report_property コマンドを実行た結

果を示します。 puts コマンドでは文字列が処理されるのでオブジェクトの名前が表示され、 report_property

コマンドではオブジェクトのプロパティとその値が返されていることに注目してください。

set inst [get_cells cpuEngine]cpuEngine





puts $instcpuEngine

report_property $instProperty Type Read-only ValueCLASS string true cellFILE_NAME string true C:/2014.1/cpu/project_1.srcs/sources_1/imports/netlist/top.edfIS_BLACKBOX bool true 0IS_PRIMITIVE bool true 0IS_SEQUENTIAL bool true 0LINE_NUMBER int true 812044NAME string true cpuEnginePRIMITIVE_COUNT int true 11720REF_NAME string true or1200_top

どのクラスのデザインオブジェクトに対しても、カスタムプロパティを作成できます。これは、メモリ内のデザイ

ンオブジェクトにスクリプトからの情報を追記する場合に有益です。次の例では、セルオブジェクトに対して

SELECTED というプロパティを作成しています。プロパティ値は整数として定義されます。

create_property SELECTED cell -type int

オブジェクトのクラスにプロパティを作成すると、特定のオブジェクト上で set_property および

get_property コマンドを使用して管理し、 list_property および report_property コマンドを使用してレ

ポートできます。次の例では、名前が *aurora_64b66b* というパターンに一致するすべてのセルの SELECTED

プロパティを 1 に設定しています。

set_property SELECTED 1 [get_cells -hier *aurora_64b66b*]





名前を使用したオブジェクトの取得

ほとんどのデザインは、階層的に接続されたブロックまたはモジュールで構成されています。ボトムアップ、トッ

プダウン、またはミドルアウトで構築されたデザインのいずれでも、デザイン階層で特定のオブジェクトを検索す

るのは一般的なタスクです。

get_* コマンドでは、デフォルトではデザイン階層の上位のオブジェクトのみが返されます。 get_* コマンドを

使用する前に current_instance コマンドを使用すると、デザインの特定の階層インスタンスでデザインオブ

ジェクトを検索できます。検索範囲をデザインの上位に戻すには、 current_instance コマンドを引数を指定

せずに実行します。

図 2 に、上位にモジュール A および B がインスタンシエートされている例を示します。モジュール A には a1 およ

び a2 階層インスタンスが含まれ、モジュール B には b1 および b2 階層インスタンスが含まれます。 a1、 a2、 b1、お

よび b2 には、それぞれ下位セル (Unisim インスタンス) が含まれます。

# Set the current instance of the design to module B.current_instance B get_cells * ; # Returns b1 and b2, cells found in the level of the current instance.get_nets * ; # Returns nets from module B, the current instance.# Reset the current instance to the top-level of the design.current_instance get_cells * ; # Returns A and B, located at the top-level of the design.

get_* コマンドでは上位または current_instance で指定した現在のインスタンスのレベルでのみ検索が実行されま

すが、現在のインスタンスに対する階層インスタンス名を含む検索パターンを指定できます。デフォルトでは、現

在のインスタンスはデザインの上位に設定されています。上位からインスタンス b1 を参照するには、次のよう

に指定します。

get_cells B/b1 ; # Search the top-level for an instance with a hierarchical name.

‐hierarchical オプションの使用

get_* コマンドでは、デフォルトでは現在のインスタンスのレベルでのみオブジェクトが検索されますが、

-hierarchical オプションを使用すると、現在のインスタンスのレベルから各デザイン階層を検索できます。


図 2:デザイン階層の検索





get_cells -hierarchical * ; # Returns all cells of the design.get_nets -hier *nt* ; # Returns all hierarchical nets that match *nt*.

-hierarchical オプションでは、オブジェクトの完全な階層名に対してではなく、デザイン階層の各レベルで指

定された名前のパターンが検索されます。通常、 -hierarchical を使用する場合、指定する検索パターンに階層

区切り文字を含めないでください。そうでないと、オブジェクトは返されません。ただし、合成中にネットリスト

が部分的にフラット化されており、フラット化されたネットリストレベルを示すのにも階層区切り文字が使用され

ている場合は例外です。この場合、階層区切り文字は名前の階層レベルを示しており、メモリ内に読み込まれてい

るデザインの階層レベルを示しているわけではないので、階層区切り文字を検索パターンに使用できます。

次の例は図 2 に基づいており、階層ネットリストのみを示します。

get_cells -hierarchical B/* ; # No cell is returned.get_cells -hierarchical b* ; # B/b1 and B/b2 are returned.

-hierarchical を使用した検索は、 current_instance コマンドを使用して階層インスタンスを指定し、各階層

レベルで指定の名前のパターンを手動で検索するのと同じです。次の例では、図 2 でこの手動検索を実行していま

す。

set result {}foreach hcell [list "" A B A/a1 A/a2 B/b1 B/b2] {current_instance $hcell ;# Move scope to $hcellset result [concat $result [get_cells <pattern>]]current_instance ;# Return scope to design top-level

}

重要: -hierarchical を -regexp と共に使用する場合、検索パターンは完全な階層名と比較され、検索パターン

として「B/*」を指定した場合にこのパターンに一致するセル名が返されます。たとえば、図 2 で get_cells

-hierarchical -regexp B/.* を実行すると、ブロック B の下のすべてのセルが返されます。 -regexpの詳細

は、『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835) [参照 1] を参照してください。





‐filter および ‐regexp オプションの使用

Vivado Design Suite では、 get_* コマンドを使用してオブジェクトのサブセットを選択するのに、 -filter および

-regexp オプションを -hierarchical オプションと共に使用できます。

次の表に、コマンドで指定したパターンに対する -hierarchical/-filter/-regexp オプションの効果を示しま

す。

get_* [-hierarchical] [-filter] [-regexp] pattern

注記: オブジェクトのローカル名は、現在の階層レベル (current_instance) からの名前の一部です。親階層から

継承された部分の名前は含まれません。

注記:デザインの一部がフラット化されている場合、フラット化されたレベルに含まれるオブジェクトのローカル名

には階層区切り文字が含まれます。この場合、名前のこの部分の階層区切り文字は、区切り文字としてはなく、リ

テラル文字として扱われます。

注記: -filter オプションはフィルター式を指定し、式内のパターン比較はグローバル条件式のフォーマットに従

います。フィルター式ではオブジェクトのプロパティに基づく文字列の比較が実行され、必要に応じて複雑なもの

にできます。フィルター式に NAME プロパティを使用すると、文字列比較にオブジェクトのローカル名ではなく完

全な階層名が使用されます。ただし、現在の階層レベル (current_instance) に含まれるオブジェクトのみが検索

されます。 -hierarchical を -filter と共に使用すると、現在の階層レベルおよびその下位にあるオブジェクト

に対してフィルター処理が実行されます。 -regexp を -filter と共に使用すると、フィルター式内のパターン比

較は正規表現に従います。

表 1: ‐hierarchical/‐filter/‐regexp オプションの影響

‐hierarchical ‐filter ‐regexp 結果

pattern は現在の階層レベル (current_instance) にあるオブジェ

クトのローカル名と比較されます。

ありpattern は現在の階層レベル (current_instance) およびその下位

にあるオブジェクトのローカル名と比較されます。

あり


クトに適用されるフィルター式となります。 NAME プロパティがオブ

ジェクトの完全な階層名と比較されます。

ありあり

pattern は現在の階層レベル (current_instance) およびその下位

にあるオブジェクトに適用されるフィルター式となります。 NAME プ

ロパティがオブジェクトの完全な階層名と比較されます。

ありpattern は正規表現として現在の階層レベル (current_instance)

にあるオブジェクトのローカル名と比較されます。

ありありpattern は正規表現として現在の階層レベル (current_instance)

およびその下位にあるオブジェクトのローカル名と比較されます。

ありあり


クトに適用されるフィルター式となります。 NAME プロパティがオブ

ジェクトの完全な階層名と比較されます。フィルター式は、正規表現

として適用されます。

ありありあり

pattern は現在の階層レベル (current_instance) およびその下位

にあるオブジェクトに適用されるフィルター式となります。 NAME プ

ロパティがオブジェクトの完全な階層名と比較されます。フィルター

式は、正規表現として適用されます。





注記: -regexp は、コマンドに指定された検索パターンが正規表現であることを示します。 *、 .、 [ ]、 + などの一

部の文字は正規表現では特別な意味を持つので、注意が必要です。正規表現でこれらの文字をリテラルとして使用

する場合は、エスケープ処理する必要があります。

文字列比較では大文字と小文字が区別され、常に検索文字列の冒頭および末尾にアンカーされています。検索文字

列のサブ文字列を比較する場合は、正規表現を使用するかどうかによって、次の構文を使用します。

• 正規表現を使用する場合 (-regexp のみ):.*<substring>.*

• パターンがグローバル条件式のフォーマットに従う場合 (その他のオプション): *<substring>*

次に、 cpu_hdl プロジェクトに基づく例を示します。このプロジェクトは、 Vivado IDE の Getting Started ページで

[Open Example Project] リンクをクリックして開くことができます。

• 現在のインスタンスを fftEngine/fftInst/ingressLoop[7].ingressFifo に変更:

vivado% current_instance fftEngine/fftInst/ingressLoop[7].ingressFifofftEngine/fftInst/ingressLoop[7].ingressFifo

• 現在のインスタンスの下にあるすべてのセルを取得 (階層セルは 1 つのみ):

vivado% get_cellsfftEngine/fftInst/ingressLoop[7].ingressFifo/buffer_fifovivado% get_cells -hierfftEngine/fftInst/ingressLoop[7].ingressFifo/buffer_fifo fftEngine/fftInst/ingressLoop[7].ingressFifo/buffer_fifo/infer_fifo.two_rd_addr_reg[8]_i_1__29 … (154 other cells)

• 現在のインスタンスおよびその下位にあるセルのローカル名には、 ingressLoop は含まれません。文字列

ingressLoop は親セルから継承されたものであり、完全な階層名の一部です。

vivado% get_cells *ingressLoop*WARNING: [Vivado 12-180] No cells matched '*ingressLoop*'.vivado% get_cells *ingressLoop* -hierWARNING: [Vivado 12-180] No cells matched '*ingressLoop*'.

• -filter オプションを使用すると、 NAME プロパティは完全な階層名と一致します。

vivado% get_cells -filter {NAME =~ *ingressLoop*}fftEngine/fftInst/ingressLoop[7].ingressFifo/buffer_fifovivado% get_cells -filter {NAME =~ *ingressLoop*} -hierfftEngine/fftInst/ingressLoop[7].ingressFifo/buffer_fifo fftEngine/fftInst/ingressLoop[7].ingressFifo/buffer_fifo/infer_fifo.two_rd_addr_reg[8]_i_1__29 … (154 other cells)

• パターン *reg[*]* に一致するセルを検索:

vivado% get_cells *reg[*]*WARNING: [Vivado 12-180] No cells matched '*reg[*]*'.vivado% get_cells *reg[*]* -hierfftEngine/fftInst/ingressLoop[7].ingressFifo/buffer_fifo/infer_fifo.wr_addr_reg[9]_i_1__15 … (109 other cells)vivado% get_cells -hier -regexp {.*reg\[.*\].*}fftEngine/fftInst/ingressLoop[7].ingressFifo/buffer_fifo/infer_fifo.wr_addr_reg[9]_i_1__15 … (109 other cells)vivado% get_cells -hier -regexp {.*reg[.*].*}WARNING: [Vivado 12-180] No cells matched '.*reg[.*].*'.





後のクエリ get_cells -hier -regexp {.*reg[.*].*} で一致するセルがないのは、角かっこ ([]) がエス

ケープ処理されていないため、セル名のリテラル文字としてではなく、正規表現の特殊文字として扱われているか

らです。

フィルター式で値の範囲を指定する必要がある場合は、 -filter に加えて -regexp オプションを使用する必要が

あります。たとえば、次のコードでは *reg[0]* から *reg[16]* までのセルのみが取得されます。この正規表現

は .*reg\[[0-9]\].* または .*reg\[1[0-6]\].* に一致するものを検索します。

vivado% get_cells -hierarchical -regexp -filter {NAME =~ ".*reg\[([0-9]||1[0-6])\].*"}

次の例では、どちらのコマンドも、 CLB*X*Y* に一致するタイルで、 CLB*X1Y* から CLB*X16Y* (X が 1 ～ 16) を除

くものが返されます。

vivado% get_tiles -regexp -filter {NAME !~ "CLB.*X([1][0-6]|[0-9])Y.*" && TYPE=~ "CLB.*"}vivado% get_tiles -regexp -filter {NAME !~ "CLB.*X1[0-6]Y.*" && NAME !~ "CLB.*X[1-9]Y.*" && TYPE=~ "CLB.*"}

ピンの検索

ピンの名前は、そのピンが属するインスタンスに基づいています。ピンを検索する場合、階層区切り文字を使用し、

インスタンス名とピン名を区切る必要があります。次の例は、図 3 に示されています。

# Current instance is set to design top-levelget_pins B/* ; # Returns B/clk B/din0 B/din1 B/dout0 B/dout1


図 3: ピン名の検索





get_pins B/b2/*/O ; # Returns B/b2/data_reg_i_1/Ocurrent_instance B/b2 ; # Change scope to B/b2get_pins *_reg/D ; # Returns B/b2/data_reg/D

ピンを検索する際、 -hierarchical も使用できます。

current_instance ; # Reset to the top-level of the hierarchyget_pins -hier */D # Returns pin objects for all D pins in the design

注記: -hierarchical および -hier は同じです。オプションを識別するのに十分な文字数が記述されていれば、

Vivado Design Suite Tcl シェルで自動的にオプション名が特定されます。このため、 -of_object と -of も同じです。

フィルター結果

get_* を使用してデザインオブジェクトを検索する場合、通常必要なのは一部のオブジェクトのみです。デザイン

のすべてのネットリストオブジェクトは必要なく、たとえば特定のタイプのセルや特定の名前のネットのみなどが

必要です。要素の一部のみが返されるようにする必要があることもあります。






ワイルドカード * および ? を使用したり、 -regexp を使用したりして検索パターンを指定し、返される検索結果を

制限できます。検索する階層範囲を指定するには、 current_instance コマンドまたは -hierarchy オプション

を使用します。

次の例では、図 4 に示すデザインに対する異なる結果を示します。

get_cells * ; # Returns 2 cells: A,Bget_cells -hier * ; # Returns all cells of the design (leaf and hierarchical)get_cells -hier * -filter {NAME =~ */?1/*} ; # Returns 3 cells: A/a1/data0_i,

# A/a1/data_reg, B/b1/data_reg

-filter オプションを使用すると、 get_* コマンドの結果を特定のプロパティに基づいてフィルターできます。た

とえば次のコマンドでは、階層名が「B/b*」で開始するすべてのセルのうち、ユーザーにより配置されていないも

の (IS_LOC_FIXED が FALSE または 0) のものが返されます。

set unLoced [ get_cells -hier -filter {NAME =~ B/b* && !IS_LOC_FIXED} ]

図 4:階層デザインの検索





重要: NAME プロパティには、オブジェクトの完全な階層名が含まれます。 NAME プロパティをフィルターする場

合、 -hierarchical も含めたコマンドのほかのオプションにかかわらず、検索パターンは完全な NAME 文字列に

対して評価されます。

-filter オプションにより、結果がフィルターされてから返されます。ただし、フィルターを適用する前の検索結

果を変数に代入している場合は、それがメモリに保存されます。 filter コマンドを使用すると、変数として保存

されているリストも含め、オブジェクトの任意のリストの内容をフィルターできます。先ほどの例の場合、

$unLoced に保存されているリストを次のようにフィルターできます。

set unLocedLeaf [filter $unLoced {IS_PRIMITIVE}]

この例では、 $unLoced に保存されている結果をフィルターし、デザインのプリミティブインスタンスのみを返して

います。

重要: filter コマンドでは元の Tcl 変数は変更されないので、結果を別の Tcl 変数に保存する必要があります。

ヒント : 上記の例で、ブール型プロパティ !IS_LOC_FIXED および IS_PRIMITIVE が直接使用されていることに注目

してください。ブール型 (bool) プロパティでは、フィルター式が True か False かを直接評価できます。

フィルターパターンに使用できる演算子は等価 (==)、不等価 (!=)、含める (=~)、含めない (!~) です。数値比較演算

子 <、 >、 <=、および >= も使用できます。複数のフィルター式を AND (&&) および OR (||) で組み合わせることもで

きます。

関連性を使用したオブジェクトの検索

デザインのほかのオブジェクトに関連するオブジェクトを検索する必要がある場合があります。たとえば、特定の

セルのピンに接続されているすべてのネットや、特定のネットに接続されているすべてのセルを選択する場合など

です。 Vivado Design Suite では、デザインのエレメントをそれらの関連性を利用して検索できます。これには、

get_* コマンドで -of_objects オプションを使用します。図 5 に、インメモリデザインのオブジェクト間の関連

性を示します。





注記: これは概念的に図示したものであり、すべてのオブジェクトとその関連性をすべて表すものではありません。

-of_objects オプションをサポートする get_* コマンドのヘルプに、関連性のあるオブジェクトがリストされま

す。

get_cells -of_objects {pins, timing paths, nets, bels or sites}get_clocks -of_objects {nets, ports, or pins}get_nets -of_objects {pins, ports, cells, timing paths or clocks}get_pins -of_objects {cells, nets, bel pins, timing paths or clocks}get_ports -of_objects {nets, instances, sites, clocks, timing paths, io standards, io banks, package pins}

-of_objects オプションを使用すると、ネットオブジェクトのリストに接続されているピンオブジェクトのリス

トを簡単に取得できます。

get_pins -of_objects [get_nets -hier]

これらのネットのドライバーのリストのみを取得する場合は、 -filter オプションを使用します。

get_pins -of [get_nets -hier] -filter {DIRECTION == OUT}

注記: -of_objects で渡されるオブジェクトのリストが空の場合、 get_* コマンドで空の Tcl リストが返されます。

また、セルのリストからピンのリストを取得したり、ネットのリストからセルのリストを取得したりできます。


図 5: Vivado Design Suite でのオブジェクト間の関連性





次の例では、図 6 に示すように、インスタンス a1 からクロックピンを取得し、そのクロックピンに接続されている

ネットを取得して、そのネットに接続されているピンを取得して、さらにそのピンに接続されているネットを取得

して、後にそれらのネットに接続されているピンを取得しています。

get_pins -of [get_nets -of [get_pins -of [get_nets -of [get_pins A/a1/clk]]]]A/a2/clk A/clk A/a1/clk B/clk

後の get_pins コマンドにより、それまでに返されたピンに加え、階層モジュール B のクロックピン B/clk が

返されます。階層をまたいでクロックネットオブジェクトのプリミティブピンを取得するには、 get_pins コマン

ドの -leaf オプションを使用できます。次の例では、 -leaf を使用した場合の結果を示します。

get_pins -leaf -of [get_nets -of [get_pins -of [get_nets -of [get_pins A/a1/clk]]]]B/b1/data_reg/C A/a2/data_reg/C A/a1/data_reg/C B/b2/data_reg/C

get_nets コマンド

get_nets コマンドを使用すると、ネットがデザイン階層を通過するため、同じネットが異なる表現で返されるこ

とがあります。次に、 get_nets コマンドのオプションを使用して、ネットの適切な表現が選択されるようにする

例をいくつか示します。

次の例では、次のように定義された LUT2 の下位ピンを使用して、下位ピンに接続されているネットの異なる

セグメントをクエリします。

set mypin [get_pins{egressLoop[7].egressFifo/buffer_fifo/infer_fifo.wr_addr_reg[9]_i_1__6/I0}]


図 6:関連性を使用したオブジェクトの検索





mark_objects -color green $mypin

単純に下位ピン mypin に接続されているネットを取得すると、階層内の下位ピンに直接接続されているネット

セグメントが返されます。

select_objects [get_nets -of $mypin]

下位ピン mypin に接続されているネットのすべてのセグメントを選択するには、 -segments オプションを使用

します。

select_objects [get_nets -segments -of $mypin]


図 7: mypin 例の設定


図 8: get_nets ‐segments の例





下位ピン mypin に接続されているネットセグメントで上位階層のもののみを選択するには、 -segments オプ

ションと共に -top_net_of_hierarchical_group を使用します。これは、ネット名を小文字数で表示するの

で、デバッグ文を表示する際に有益です。

select_objects [get_nets -top_net_of_hierarchical_group -segments -of $mypin]


図 9: get_nets ‐top_net_of_hierarchical_group の例


図 10: get_nets ‐of ピンの例





タイミングパスオブジェクト

get_timing_path コマンドは、タイミングパスオブジェクトを表示するために使用できます。

get_timing_path コマンドは report_timing コマンドと同じエンジンを使用するので、ほぼ同じコマンドライ

ンオプションを使用できます。

タイミングパスオブジェクトは、スタティックタイミング解析に関連するアドバンススクリプトを実行するのに

便利なことがあります。タイミングパスオブジェクトは、 report_timing -of <timingPathObject> のよう

に使用すると、パスのフルテキストレポートを生成するためにも使用できます。

get_nets、 get_cells、または get_pins コマンドにタイミングパスオブジェクトを使用すると、そのパスの

データパスセクションにネット /セル/ピンがリストできます。ソースおよびデスティネーションクロックネット

ワーク内のデザインエレメントは、リストできません。

get_nets、 get_cells、または get_pins でタイミングパスオブジェクトから返されたオブジェクトリストは、

データパス内のデザインエレメントに基づいて分類されます。

オブジェクトの持続性

Vivado オブジェクトは、それがポイントするエレメントがメモリ内に存在する限り、持続されます。たとえば、 Tcl

変数がセルオブジェクトをポイントしていて、そのセルが後で (手動または何らかの適化段階で) 削除された場合、

そのセルオブジェクトは無効になります。この結果、それに依存するコマンドをユーザーが実行した場合に、予期

しない結果になったりクラッシュする可能性があります。

同様に、デザインまたはプロジェクトを閉じると、すべてのデザインオブジェクトが無効になるほか、その他すべ

ての Vivado オブジェクトも無効になる可能性があり、存在しない Vivado オブジェクトをポイントしているすべての

Tcl 変数が停止します。

注意: メモリに存在しないオブジェクトに依存するコマンドを実行すると、予期しない結果になったりシステムがク

ラッシュする可能性があります。

たとえば、次のコードは無効になります。

foreach port [get_ports] { # The 'port' object is used as key set dir($port) [get_property DIRECTION $port] }

foreach key [array name dir] { puts "$key -> $dir($key)" }

close_project

# All the objects have been nullified foreach key [array name dir] { # null puts "$key -> $dir($key)" }

プロジェクトを閉じると、すべてのオブジェクト (この場合はポートオブジェクト ) が無効になるので、ポートのリ

ストを表示できなくなります。





デザインを閉じてからポートのリストを表示できるようにするには、 port オブジェクトの NAME プロパティを使

用して関連する dir アレイを構築しておく必要があります。

foreach port [get_ports] { set dir([get_property NAME $port]) [get_property DIRECTION $port]}

オブジェクトのリストの処理

get_* コマンドを使用すると、返されたオブジェクトは標準の Tcl リストと同様で、同じように機能しますが、

Vivado Design Suite ではオブジェクトの 1 つのクラスのコンテナー (セル、ネット、ピン、ポートなど) が返され、標

準の Tcl リストとは異なります。ただし、このコンテナーは通常、標準の Tcl リストと同様で、同じよう機能しま

す。オブジェクトのコンテナーは Vivado Design Suite で自動的に処理されるので、ユーザーが意識する必要はありま

せん。たとえば、標準 Tcl コマンド llength をオブジェクトのコンテナーに対して使用し (get_cells の結果など

)、通常の Tcl リストでの場合と同様に、コンテナーに含まれるエレメントの数を取得できます。

Vivado Design Suite のリストを処理するビルトインの Tcl コマンドは、オブジェクトおよびオブジェクトのコンテ

ナーを完全にサポートするため拡張されています。たとえば、 lsort、 lappend、 lindex、および llength は、

オブジェクトの NAME プロパティに基づいてコンテナーを制御するよう拡張されています。これらのコマンドは、

オブジェクトのコンテナーが渡された場合、オブジェクトのコンテナーを返します。たとえば、 lsort は、

get_cells で取得したセルのコンテナーを、オブジェクトの階層名に基づいて並べ替えます。

lappend を使用するなどしてコンテナーにオブジェクトを追加できますが、現在コンテナーに含まれるオブジェク

トと同じタイプのオブジェクトしか追加できません。リストに異なるタイプのオブジェクトや文字列を追加しよう

とすると、 Tcl エラーが返されます。

次の例では、 Vivado のコンテナーを降順に並べ替え、 puts コマンドと foreach ループを使用して、オブジェクト

を 1 行に 1 つずつ表示しています。

foreach X [lsort -decreasing [get_cells]] {puts $X}wbArbEngineusb_vbus_pad_1_i_IBUF_instusb_vbus_pad_0_i_IBUF_instusbEngine1usbEngine0...

注記: lappend コマンドは Tcl コンソールでサポートされますが、 read_xdc コマンドで読み込む XDC 制約ファイ

ルではサポートされません。ただし、 lappend コマンドで取得したリストを read_xdc コマンドと互換性を持たせ

るように変換できます。次のようなコードがあるとします。

set myClocks {}lappend myClocks [get_clocks CLK1]lappend myClocks [get_clocks CLK2]lappend myClocks [get_clocks CLK3]

Tcl 変数 myClocks を、 read_xdc コマンドと互換性を持たせるようにするには、次のようにします。

set myClocks [list [get_clocks CLK1] \[get_clocks CLK2] \[get_clocks CLK3] \

]





コレクションと文字列表現

get_* コマンドでは、通常のエレメントの Tcl リストが作成されるのではなく、オブジェクトの Vivado コレクショ

ンが作成されます。 Vivado コレクションは、通常の Tcl リストと同じように動作するよう構成されています。このプ

ロセスは、ユーザーにも Tcl にもトランスペアレントです。 Vivado コレクションは Tcl リストと同様に動作し、同じ

コマンドで同じように処理されます。

Vivado コレクションは、 Vivado オブジェクトを処理する際のランタイムを短縮し、メモリ使用量を削減するために

導入されました。

Vivado コレクションを文字列に変換すると、変換されるオブジェクトの数が制限される場合があります。たとえば、

Tcl コンソールにインスタンスのリストを表示する際に、リスト (実際には Vivado コレクション) に 100,000 個のイン

スタンスが含まれる場合、初の 500 個 (デフォルトの制限) のみが表示されます。これにより、 Tcl コンソールに極

端に長い文字列が表示されるのを防ぐことができます。

オブジェクトの Vivado コレクションの文字列表現について、理解しておくことが重要です。コレクションの文字列

表現に含まれるオブジェクトの大数は、 tcl.collectionResultDisplayLimit パラメーターで指定します。

tcl.collectionResultDisplayLimit 500 integer true

このパラメーターでは、コレクションを表示するコマンドで表示可能なエレメントの大数を指定します。 0 に設定

すると、制限なしになります。デフォルトは 500 です。次に例を示します。

set_param tcl.collectionResultDisplayLimit 0set_param tcl.collectionResultDisplayLimit 1000

Vivado コレクションに tcl.collectionResultDisplayLimit パラメーターで指定されている制限を超える数の

エレメントが含まれる場合、その制限数のエレメントが文字列に変換され、文字列の後に「...」が追加されて、元

のコレクションにさらにエレメントが含まれていることが示されます。

注記: この文字列表現により元のコレクションが変更されることはなく、エレメントが失われることはありません。

注記: tcl.collectionResultDisplayLimit パラメーターは、 Vivado コレクションの文字列表現にのみ適用さ

れ、通常の Tcl リストの文字列表現には適用されません。

たとえば、デザインに 20000 個のインスタンスが含まれているとします。

vivado% set cells [get_cells -hier]vivado% llength $cells20000vivado% set var [join $cells "\n"]vivado% llength $var501vivado% lindex $var end...





出力先の指定

Vivado Design Suite の多くの Tcl コマンドでは、コマンドから返される情報を、 -file オプションを使用して印刷や

ツール外での処理用にファイルに保存したり、 -return_string オプションを使用して Vivado ツールでの処理用

に文字列として変数に保存できます。

すべてのレポートコマンドで、 -file オプションがサポートされています。大量の情報を出力するレポートコマン

ドでは、その後の解析、デザインプロジェクトの文書サポート、またはほかの部署にダウンストリーム処理用に渡

す場合などに、ファイルに出力すると有益です。次に、ファイル出力をサポートするコマンドの一部を示します。

report_datasheetreport_drcreport_powerreport_timingreport_timing_summaryreport_utilization

たとえば、 report_timing コマンドの結果をファイルに記述するには、次のコマンドを使用します。

report_timing -delay_type max -file setup_violations.rptreport_timing -delay_type min -file hold_violations.rpt

ファイル名の一部として、相対パスまたは絶対パスを指定できます。相対パスは、 Vivado ツールを起動したディレ

クトリまたは pwd コマンドで返される現在の作業ディレクトリを基準として指定します。

ヒント : パスをファイル名の一部として指定しない場合は、現在の作業ディレクトリまたは Vivado ツールを起動した

ディレクトリにファイルが作成されます。

既存のファイルにコマンドの結果を追加するには、 -file オプションと共に -append オプションを使用します。

次の例では、 1 つのファイル all_violations.rpt を作成し、 2 つのコマンドの結果を保存しています。

report_timing -delay_type max -file all_violations.rptreport_timing -delay_type min -file -append all_violations.rpt

ファイルが作成されたら、ファイルシステムからファイルを開いて確認したり書き込んだりできます。 Vivado

Design Suite Tcl コンソールには、ファイルにアクセスするさまざまなコマンドがあります。詳細は、「ファイルへの

アクセス」を参照してください。

すべての report_* コマンドでは、 -return_string オプションもサポートされています。このオプションを使

用すると、コマンドの出力が Tcl 変数に代入可能な文字列として返されます。コマンド出力を変数に代入すると、

Tcl スクリプトでのその後の処理に有益で、主要な情報を抽出してフロー制御や分岐を可能にしたり、スクリプトで

使用するほかの変数を設定したりできます。

次に、 -return_string オプションをサポートするコマンドの一部を示します。

report_clocksreport_clock_interactionreport_disable_timingreport_environmentreport_high_fanout_netsreport_operating_conditionsreport_powerreport_property





report_pulse_widthreport_route_statusreport_utilization

レポートコマンドから返された文字列を改行文字 \n で分離して、文字列をリストとして行ごとに処理できます。

set timeLines [split [report_timing -return_string -max_paths 10] \n ]

Vivado Design Suite Tcl コンソールには、文字列を操作するさまざまなコマンドがあります。詳細は、「文字列の操

作」を参照してください。

ファイルへのアクセス

ファイルシステムにファイルを記述すると、ファイルを処理するさまざまな Tcl コマンドを使用できます。ファイ

ルパス、ファイル名、ファイル拡張子など、ファイルの要素を抽出できます。ファイルに関する情報を調べる次の

ようなコマンドもあります。

• file exists filename: filename が存在し、その場所の読み取り権限がある場合は 1、それ以外の場合は

0 を返します。ファイルが既に存在しているかどうかを調べるのに使用します。

• file type filename: ファイルのタイプを示す文字列を返します。可能な値は file、 directory、

characterSpecial、 blockSpecial、 fifo、 link、 socket です。

• file dirname filename: filename の後のスラッシュまでのディレクトリ構造を後のスラッシュを含

めずに返します。

• file rootname filename: filename の後のピリオドまでの文字を後のピリオドを含めずに返します。

• file tail filename: filename の後のスラッシュより後の文字すべてを返します。

• file extension filename: filename の後のピリオド以降の文字を後のピリオドを含めて返します。

次に、 Tcl コマンドのいくつかの例を示します。

set filePath {C:/Data/carry_chain.txt}file dirname $filePath ; # Returns C:/Datafile tail $filePath ; # Returns carry_chain.txtfile extension $filePath ; # Returns .txt

report_* コマンドまたは write_* コマンドでファイルを作成したら、 Tcl スクリプトでファイルを開いて、その

内容を読み出したり、追加の内容を記述したりできます。ファイルを開いたり閉じたり、ファイルの読み出しまた

は書き込みを実行するには、次の Tcl コマンドを使用できます。

• open <filename> [access] [perms]: filename を開き、ファイルにアクセスするのに使用したファイル

ハンドル (fileID) を返します。必要に応じてファイルハンドルを参照できるようにするため、 fileID を Tcl 変数

に代入するのが一般的です。新しいファイルの権限は、 perms とプロセス umask の組み合わせで設定します。

access モードは、開いたファイルの読み取り権および書き込み権を指定します。一般的なアクセスモードは

次のとおりです。

° r: 読み出しモード。ファイルが存在している必要があり、作成されません。アクセスモードを指定しない

場合、これがデフォルトです。

° w: 書き込みモード。ファイルが存在しない場合は、作成されます。データはファイルの冒頭から記述され、

既存のファイルの内容は切り捨てられるか、上書きされます。

° a: 追加モード。ファイルが存在しない場合は、作成されます。データはファイルの末尾に記述され、既存

のファイルの内容に追加されます。





• read [-nonewline] fileId: fileId から残りすべてのバイトを読み出し、オプションで後の文字が改行

\n の場合はその後の文字を破棄します。ファイルを開いた直後にこの形式を使用すると、 read コマンドで

ファイル全体が一度に読み出されます。

• read fileId numBytes: fileId から指定したバイト数 numBytes を読み出します。この形式は、ファイル

のブロックをファイルの後まで読み出す場合に使用します。

• eof fileId: fileId で EOF (End Of File) が発生した場合は 1、それ以外の場合は 0 を返します。

• gets fileId [varName]: fileId から次の行を読み出します。改行文字は破棄されます。 $varName を指

定した場合は行の文字列をその変数に代入し、それ以外の場合は文字列をコマンドシェルに返します。次に、

gets コマンドの異なる形式を示します。

gets $fileHandleAppend line 4 of file.gets $fileHandle line28puts $lineAppend line 5 of file.set line [gets $fileHandle]Append line 6 of file.puts $lineAppend line 6 of file.

上記の例では、 $fileHandle がファイルを開いたときに返されるファイルハンドルです。初の例は gets

の単純な形式で、出力を代入する Tcl 変数は指定していません。この場合、出力は stdout に返されます。 2 番

目の例では出力を $line という変数に代入しており、 gets コマンドで読み出された文字数 28 が返されます。

注記: gets コマンドの戻り値を Tcl 変数に代入できますが、コマンドの形式によって、ファイルの内容または

gets コマンドで読み出された文字数が代入されます。

• puts [-nonewline] [fileId] string: 指定した fileId に文字列を書き込みます。オプションで、改行

文字 \n を省くこともできます。 puts コマンドのデフォルトの fileId は stdout です。

• close fileId: 開いているファイルチャネル fileId を閉じます。 Tcl スクリプトで開いたファイルは必ず閉

じてください。そうしないと、 Vivado アプリケーションでメモリリークやその他の問題が発生する可能性があ

ります。

次の例では、ファイルを読み出しアクセスモードで開き、ファイルハンドルを $FH に代入して、 1 つの操作でファ

イルの内容を読み出して $content に代入し、その内容を Tcl リストに分割しています。完了したら、ファイルを

閉じます。

set FH [open C:/Data/carry_chains.txt r]set content [read $FH]; # The entire file content is saved to $contentforeach line [split $content \n] {# The current line is saved inside $line variableputs $line

}close $FH

注記:パフォーマンスおよびメモリの面から、サイズの大きいファイルを 1 回の操作で読み出すことはお勧めしませ

ん。

次の例では、ファイル全体を一度に読み出してから結果を解析するのではなく、ファイルを 1 行ずつ後まで読み

出し、 stdout に行数と行の内容を出力しています。完了したら、ファイルを閉じます。

set FH [open C:/Data/carry_chains.txt r]set i 1while {![eof $FH]} {





# Read a line from the file, and assign it to the $line variableset line [gets $FH]puts "Line $i: $line"incr i

}close $FH

次の例では、デザインのすべての I/O ポートをその方向と共に名前順に並べ替えて、ファイル ports.rpt に書き込

んでいます。

set FH [open C:/Data/ports.rpt w]foreach port [lsort [get_ports *]] {puts $FH [format "%-18s %-4s" $port [get_property DIRECTION $port]]

}close $FH

上記の例では、ファイルを書き込みモードで開いています。読み出しモードとは異なり、書き込みモードではファ

イルが存在していない場合は作成され、ファイルが存在している場合は上書きされます。既存のファイルの後に

新しい内容を追加するには、ファイルを追加モードで開く必要があります。

文字列の操作

-return_string オプションを使用すると、 report_* コマンドの出力を stdout ではなく Tcl 文字列として返す

ことができます。文字列は Tcl 変数に代入したり、解析または処理できます。

set rpt [report_timing -return_string]

文字列を変数に代入すると、文字列を処理するさまざまな Tcl コマンドを使用できます。

• append string [arg1 arg2 ... argN]: 指定した args を string の後に追加します。

• format formatString [arg1 arg2 ... argN]: 文字列を formatString テンプレートで指定したフォーマットの形

式にします。テンプレートは、 sprintf で使用されるように % 変換指示子を使用して指定する必要がありま

す。追加の引数 arg は、フォーマットされた文字列内で置換する値を指定します。

• regexp [switches] exp string: 正規表現 exp が string に一致する場合は 1、それ以外の場合は 0 を返

します。 -nocase オプションを指定すると、大文字/小文字は区別されません。

• string match pattern string: glob pattern が string に一致する場合は 1、それ以外の場合は 0 を返し

ます。

• scan string formatString [varName1 varName2 ...]: 指定の string から値を抽出して変数

varName に代入し、 sscanf と同じように % 変換指示子を使用して formatString を適用します。 varName

を指定しない場合は、値のリストが stdout に出力されます。

• string range string first last: string から、文字インデックス first から last までを、それらを

含めて返します。

• string compare string1 string2: 2 つの文字列に対して辞書式比較を実行し、 string1 が string2 よ

り前の場合は -1、 2 つが同じ場合は 0、 string1 が string2 より後の場合は 1 を返します。

• string last string1 string2: string2 で string1 が初に現れた文字インデックスを返します。

string2 で string1 が見つからなかった場合は -1 を返します。

• string length string: string の文字数を返します。





次の例では、 -return_string を使用して report_timing コマンドの結果を $report Tcl 変数に代入し、各パ

スの始点、終点、パスグループ、およびパスタイプを抽出して、後にそのパスのサマリを Tcl コンソールに出力

しています。

# Capture return string of timing report, and assign variablesset report [report_timing -return_string -max_paths 10] set startPoint {}set endPoint {}set pathGroup {}set pathType {}

# Write the header for string outputputs [format " %-12s %-12s %-20s -> %-20s" "Path Type" "Path Group" "Start Point" "End Point"]puts [format " %-12s %-12s %-20s -> %-20s" "---------" "----------" "-----------" "---------"]

# Split the return string into multiple lines to allow line by line processingforeach line [split $report \n] {if {[regexp -nocase -- {^\s*Source:\s*([^[:blank:]]+)((\s+\(?)|$)} $line - startPoint]} {} elseif {[regexp -nocase -- {^\s*Destination:\s*([^[:blank:]]+)((\s+\(?)|$)} $line - endPoint]} {} elseif {[regexp -nocase -- {^\s*Path Group:\s*([^[:blank:]]+)\s*$} $line - pathGroup]} {} elseif {[regexp -nocase -- {^\s*Path Type:\s*([^[:blank:]]+)((\s+\(?)|$)} $line - pathType]} {puts [format " %-12s %-12s %-20s -> %-20s" $pathType $pathGroup $startPoint $endPoint]}}

次は、このコードの出力例です。

Path Type Path Group Start Point -> End Point --------- ---------- ----------- -> --------- Setup bftClk ingressLoop[0]/ram/CLKBWRCLK -> transformLoop[0].ct/xOutReg_reg/A[0]Setup bftClk ingressLoop[0]/ram/CLKBWRCLK -> transformLoop[0].ct/xOutReg_reg/A[10]Setup bftClk ingressLoop[0]/ram/CLKBWRCLK -> transformLoop[0].ct/xOutReg_reg/A[11]Setup bftClk ingressLoop[0]/ram/CLKBWRCLK -> transformLoop[0].ct/xOutReg_reg/A[12]Setup bftClk ingressLoop[0]/ram/CLKBWRCLK -> transformLoop[0].ct/xOutReg_reg/A[13]Setup bftClk ingressLoop[0]/ram/CLKBWRCLK -> transformLoop[0].ct/xOutReg_reg/A[14]Setup bftClk ingressLoop[0]/ram/CLKBWRCLK -> transformLoop[0].ct/xOutReg_reg/A[15]Setup bftClk ingressLoop[0]/ram/CLKBWRCLK -> transformLoop[0].ct/xOutReg_reg/A[16]Setup bftClk ingressLoop[0]/ram/CLKBWRCLK -> transformLoop[0].ct/xOutReg_reg/A[17]Setup bftClk ingressLoop[0]/ram/CLKBWRCLK -> transformLoop[0].ct/xOutReg_reg/A[18]





ループの制御

Tcl には、 for、 foreach、 while など、コードのセクションを繰り返すビルトインコマンドがあります。

これらのコマンドの構文は、次のとおりです。

for start testCondition next bodyforeach varname list bodywhile testCondition body

上記のコマンドでは、各反復で Tcl スクリプトの body 全体が実行されますが、 Tcl にはループの制御フローを変更す

る break および continue の 2 つのコマンドがあります。

break 文はループコマンドを中止するために使用し、 continue 文はループの次の反復にジャンプするために使用

します。

注記: プロシージャ内で実行する場合、ループは return コマンドを使用して中止できます。この場合、ループが中

止されるだけでなく、制御もループを呼び出したプロシージャに戻されます。

たとえば、 1 行に 1 つのインスタンス名を含む、セル名がリストされたファイルがあるとします。次のサンプル

コードは、このファイルを読み込み、現在デザインに存在するセル名のみを含む Tcl リストを作成します。先ほど示

した get_file_content プロシージャを再利用しています。現在のデザインで見つからないセル名が指定の数を

超えた場合、ファイルの処理を停止します。

set valid_cell_names [list]set error 0set max_errors 1000foreach line [split [get_file_content ./all_cell_names.lst] \n] { if {[get_cells $line] == {}} { # cell name not found puts " Error - cell $line not found " incr error if {$error > $max_errors} { puts " Too many errors occured. Cannot continue " break } else { # Go to next cell name continue } } lappend valid_cell_names $line}

puts " [llength $valid_cell_names] valid cells have been found "





エラー処理

変数の有効性チェック

Tcl スクリプトを記述する際は、コーナーケース (まれにしか発生しないケース) およびコードでエラーが発生する可

能性のある条件を必ずチェックすることをお勧めします。適切なチェックを実行することにより、スクリプトの問

題やスクリプトが正しく使用されていないときにユーザーにメッセージを表示できます。チェックを正しく実行し

ない場合、何が問題なのか、何を直したらよいかなどの情報なしで、スクリプトが停止してしまいます。

例 1: ファイルを読み出し /書き込みで開いたときのチェック (スクリプトに問題がある例)。

if {[file exists $filename]} { set FH [open $filename r] if {$FH != {}} { # The file is opened, do something # … close $FH } else { puts " File $filename could not be opened" }} else { puts " File $filename does not exist"}

上記のスクリプトのアルゴリズムは正しいように見えますが、 open コマンドで下位レベルの Tcl エラー

(TCL_ERROR) が生成され、ファイルを開けなかった場合にスクリプトが停止します。例 3 では、このスクリプトを

改善した例を示します。

例 2: get_* コマンドを使用した後に Vivado オブジェクトが有効であるかをチェック。

proc get_pin_dir { pinName } { if {$pinName == {}} { puts " Error - no pin name provided" return {} } set pin [get_pins $pinName] if {$pin == {}} { puts " Error - pin $pinName does not exist" return {} } set direction [get_property DIRECTION $pin] return $direction}

get_* コマンドを使用した後に Vivado オブジェクトが存在するかどうかを調べることは、これらのオブジェクトを

ほかのコマンド (filter、 get_* など) で使用する場合に特に重要です。

Tcl エラーの処理

一部のビルトイン Tcl コマンド (およびユーザープロシージャ ) は、エラーがプログラムにより検出されない場合、

Tcl エラー (TCL_ERROR) を生成してスクリプトを停止することがあります。たとえば file コマンドは、ファイル

を開くことができないと、 TCL_ERROR を生成します。





Tcl には、プログラムを正しく実行し TCL_ERROR 状態を検出できるようにビルトインの catch コマンドがありま

す。このコマンドは、エラーが検出された場合は 1 を返し、検出されなかった場合は 0 を返します。 catch コマン

ドは、 1 つのコマンドまたはコマンドのグループに対して使用できます。

catch コマンドの基本的な構文は、次のとおりです。

catch script [varname]

ここで、 script は 1 つの Tcl コマンドまたは Tcl コマンドのグループ、 varname は TCL_ERROR を説明するメッ

セージを保存する変数の名前です。

注記:引数 varname は省略できます。

通常、 catch コマンドは次のように使用されます。

If {[catch script errorstring]} { # A low-level TCL_ERROR happened puts " Error - $errorstring "} else { # No TCL_ERROR was generated puts " The code completed successfully "}

例 1 は、 catch コマンドを使用してファイルを開くことができない場合を考慮することにより、より適切なスクリ

プトとなります。

例 3: ファイルを読み出し /書き込みで開いたときのチェック (正しいスクリプト例)。

if {[file exists $filename]} { if {[catch { set FH [open $filename r] } errorstring]} { puts " File $filename could not be opened : $errorstring" } else { # The file is opened, do something # … close $FH }} else { puts " File $filename does not exist"}

Tcl エラーは、 error コマンドを使用しても生成できます。たとえば、 catch コマンドで検出した TCL_ERROR を

上位に伝搬する場合に使用できます。 error コマンドは、スクリプトでコーナーケースがサポートされていない場

合や、コードで予期されない状況が発生した場合に、 TCL_ERROR を生成するために使用できます。

たとえば次のプロシージャは、ファイルの内容を返すか、ファイルを開くことができない場合は TCL_ERROR を生

成します。

proc get_file_content { filename } { if {[catch { set FH [open $filename r] set content [read $FH] close $FH } errorstring]} { error " File $filename could not be opened : $errorstring " } return $content}





プロシージャ get_file_content を catch コマンドで呼び出すと、発生する可能性のあるエラーを検出できま

す。

if {[catch { set content [get_file_content ./myreport.rpt] } errorstring]} { puts " The following error was generated: $errorstring "} else { puts " The content of the file is: $content "}

例 2 も、例 4 に示すように、間違った条件が発生した場合に TCL_ERROR を生成するよう改善できます。

例 4: Vivado オブジェクトが有効であるかをチェックし、有効でない場合は TCL_ERROR を生成 (改善後)。

proc get_pin_dir { pinName } { if {$pinName == {}} { error " Error - no pin name provided" } set pin [get_pins $pinName] if {$pin == {}} { error " Error - pin $pinName does not exist" } set direction [get_property DIRECTION $pin] return $direction}

環境変数へのアクセス

Tcl グローバル変数 env を使用すると、環境変数に読み出し専用モードでアクセスできます。 env 変数は、 Tcl イン

タープリター内でスタートアップ時に自動的に作成および初期化される Tcl 配列です。

注記:初期化後は、 env 変数への変更は Tcl インタープリター外の環境には適用されません。同様に、 Tcl インタープ

リターの開始後に環境変数に加えられた変更は、 env 変数には反映されません。

env 配列のキーは、 Vivado Design Suite の開始時点の環境変数です。キーでは大文字/小文字が区別されます。


Vivado% puts "The PATH variable is $env(PATH) "

すべての Unix 環境変数のリストを取得するには、次の構文を使用します。

Vivado%: set all_env_var [array names env]

環境変数 (env 配列へのキー ) が存在するかは、 info コマンドを使用して確認できます。たとえば MYVARNAME を確

認するには、次の構文を使用します。

Vivado% if {[info exists env(MYVARNAME)]} { … }

env 配列はグローバル変数なので、グローバルとして宣言すると、プロシージャ内で参照できます。






proc print_env {} { global env puts " UNIX Environment:" foreach var [lsort [array names env]] { puts " $var : $env($var)" }}

外部プログラムの呼び出し

外部プログラムを Tcl 内から呼び出して、戻された結果を取り込むことができます。外部プログラムまたはコマンド

を呼び出す場合、未知の Tcl コマンドを OS (Windows/Linux) に送信して実行する自動メカニズムもありますが、常に

手動で指定することをお勧めします。これには、 exec コマンドを使用します。

スクリプトがすべてのホスト OS (Windows または Linux) および Vivado モード (Tcl モード、 GUI、またはバッチモー

ド ) で動作するようにするためには、 exec コマンドを使用して結果が同じになるようにしておくことが重要です。

次の例 (Linux) では、 ls コマンドを呼び出して、 run ディレクトリの下のすべてのファイルとディレクトリのリス

トを取得しています。

vivado% set result [exec ls]vivado% foreach element [split $result \n] { ... }

Windows での同等の例は次のとおりです。

vivado% set result [exec cmd /c dir /B]vivado% foreach element [split $result \n] { ... }

exec を付けずに ls コマンドを呼び出すと、一部の Vivado モードでスクリプトがエラーになる可能性があるので、

注意してください ( 「Vivado IDE (統合設計環境)/Tcl モード vs バッチモード」を参照)。

次の例では、 Perl スクリプトを実行して、その結果を Tcl 環境に送信しています。 exec コマンドで /bin/perl (

ユーザー環境と一致すると想定) を呼び出すことで、 Perl スクリプト自体が呼び出されます。

vivado% set result [exec /bin/perl <path_to>/my_perl_script.pl]

Vivado IDE (統合設計環境)/Tcl モード vs バッチモード

Vivado IDE (統合設計環境) または Tcl モードで実行される Tcl コンソール (vivado -mode tcl または vivado

-mode gui) は、バッチモードで実行されるもの (vivado -mode batch) とは少し異なります。

このビヘイビアーは Tcl 固有のもので、 Vivado ツールとは関係ありません。根本的な原因については、ウェブを参照

してください。

インタラクティブなセッション (Tcl または GUI モード ) では、 Vivado は tclsh モードで実行されますが、バッチ

モードでは Tcl スクリプトモードで実行されます。





Tcl コンソールは 3 つすべてのモードでほぼ同じように動作しますが、 Tcl 環境では少しだけ異なります。まず、

バッチモードでは、未知のコマンドが OS に送信されて実行されることはありません。スクリプトが 3 つの Vivado

モードすべてで動作するようにするには、 exec コマンドを指定して、外部プログラムを実行する必要があります。

カスタムデザインルールチェック (DRC) の作成

Vivado Design Suite では、 Tcl でカスタムデザインルールチェック (DRC) を定義し、使用できます。カスタム DRC

を作成する際は、次の点に注意してください。

• デザインオブジェクトまたはデザインオブジェクトの属性、およびデザインルールを定義するチェック関数を

取得する Tcl チェッカープロシージャを記述します。 Tcl チェッカープロシージャは別の Tcl スクリプトで定義

し、 report_drc を実行する前に Vivado Design Suite に読み込む必要があります。 Tcl チェッカープロシージャ

内では、 create_drc_violation コマンドを使用してデザインでルールをチェックした際に検出される違反

を指定します。 create_drc_violation コマンドは違反オブジェクトをインメモリデザインに作成するの

で、そのプロパティをレポートして処理できます。

• create_drc_check コマンドを使用して、 Tcl チェッカープロシージャをユーザー定義 DRC に関連付けます。

report_drc コマンドを実行する際、このルールを名前で呼び出します。

• create_drc_ruledeck コマンドを使用して、 DRC ルールデックを作成します (オプション)。 DRC ルール

デックは、複数の DRC をグループ化したものです。作成した DRC ルールデックには、 add_drc_ruledeck

コマンドを使用して、ユーザー定義 DRC およびあらかじめ定義された DRC を追加できます。

• report_drc コマンドを実行し、デザインをデザインルールに対してチェックします。 report_drc を実行する

際、 DRC ルールデック、ユーザー定義デザインルールチェック、またはあらかじめ定義された DRC を指定で

きます。

Tcl チェッカープロシージャの作成

Tcl チェッカープロシージャは、チェックするデザインオブジェクトを選択し、デザインオブジェクトに対して必

要なテストまたは評価を実行して、エラーに関連するオブジェクトを特定する DRC 違反オブジェクトを返します。

次の Tcl スクリプトは、WRITE_B バスの幅をチェックする dataWidthCheck Tcl チェッカープロシージャを定義し

ています。 report_drc を実行する前に、この Tcl スクリプトファイルを Vivado Design Suite に読み込む必要があり

ます。 Tcl チェッカープロシージャの詳細は、「Tcl スクリプトの読み込みと実行」を参照してください。

# This is a simplistic check -- report BRAM cells with WRITE_WIDTH_B wider than 36.proc dataWidthCheck {} {# list to hold violationsset vios {}# iterate through the objects to be checkedforeach bram [get_cells -hier -filter {PRIMITIVE_SUBGROUP == bram}] {set bwidth [get_property WRITE_WIDTH_B $bram]if { $bwidth > 36} {# define the message to report when violations are foundset msg "On cell %ELG, WRITE_WIDTH_B is $bwidth"set vio [ create_drc_violation -name {RAMW-1} -msg $msg $bram ]lappend vios $vio}; # End IF

}; # End FORif {[llength $vios] > 0} {return -code error $vios





} else {return {}

}; # End IF} ; # End PROC

proc 定義からわかるように、 dataWidthCheck プロシージャに引数はなく、必要な情報はすべてデザインから取

得されます。空のリスト変数 $vios を作成し、 create_drc_violation コマンドで返された違反オブジェクトを

保存します。

dataWidthCheck プロシージャは、デザインのすべての BRAM セルに対して WRITE_WIDTH_B プロパティの評価を実

行します。ブロック RAM セルの WRITE_WIDTH_B が 36 を超える場合、 DRC 違反が指定のメッセージ ($msg) で作

成されます。メッセージには、セルのプレースホルダー値 %ELG とバス幅 $bwidth が含まれます。

dataWidthCheck プロシージャでは、 create_drc_violation コマンドで 1 つのオブジェクト $bram のみが返

され、メッセージ文字列に定義されている %ELG プレースホルダーに代入されます。 create_drc_violation コ

マンドでは、ネットリストオブジェクト (%ELG)、クロック領域 (%CRG)、デバイスサイト (%SIG)、およびパッケー

ジ I/O バンク (%PBG) のプレースホルダーがサポートされます。

重要: create_drc_violation コマンドで渡される順序とタイプが、 create_drc_check コマンドの -msg の指

定と一致している必要があります。

WRITE_WIDTH_B プロパティの幅が指定の値を超えているブロック RAM が検出されるたびに、

create_drc_violation で違反オブジェクトが作成されます。違反オブジェクトは、名前は関連付けられている

Vivado Design Suite の DRC ルールの名前と同じになり、あらかじめ定義されたメッセージ文字列を含み、ルールに

違反するオブジェクトを特定します。デザインルール違反で返されるオブジェクトには、セル、ポート、ピン、

ネット、クロック領域、デバイスサイト、パッケージ I/O バンクなどがあります。違反からのメッセージ文字列に

は、特定のプロパティ値などのほかの情報を含めることもでき、 DRC レポートに必要な詳細情報を提供できます。

違反が検出された場合、 dataWidthCheck プロシージャから report_drc コマンドにチェックの結果を通知する

エラーコードが返されます。

return -code error $vios

エラーコードに加え、 $vios 変数により、プロシージャで作成された違反オブジェクトのリストが返されます。

DRC チェックの作成

Tcl チェッカープロシージャを定義したら、 Vivado Design Suite 内での DRC レポートシステムの一部として DRC を

定義する必要があります。

まず create_drc_check コマンドを使用して、新しいデザインルールを登録します。このコマンドでは、ユー

ザー定義ルールチェックに固有の名前を指定する必要があります。この名前は、 Tcl チェッカープロシージャで作

成した違反の名前と一致している必要があります。 DRC ルールデックにチェックを追加する際や report_drc を

実行する際に、この固有名を指定する必要があります。先ほど定義した dataWidthCheck Tcl チェッカープロシー

ジャでは、 create_drc_violation コマンドで RAMW-1 という名前を使用しています。また、

create_drc_check コマンドでは、ルールをチェックしたときに実行する Tcl チェッカープロシージャの名前も指

定する必要があります。上記の例では、 -rule_body の引数として dataWidthCheck を指定し、 report_drc を

実行する前に Vivado Design Suite に読み込む必要があります。

create_drc_check -name {RAMW-1} -hiername {RAMB Checks} \-desc {Block RAM Data Width Check} -rule_body dataWidthCheck -severity Advisory

DRC をカテゴリにグループ化し、レポート用にルールの説明を指定することもできます。





違反が検出されたときに DRC レポートに追加するメッセージを定義できます。デフォルトでは、 Tcl チェッカープ

ロシージャの create_drc_violation で作成されたメッセージが DRC オブジェクトに渡されます。この場合、

create_drc_violation で定義されたメッセージが DRC レポートに記述されます。

DRC オブジェクトには is_enabled プロパティがあり、 set_property コマンドを使用して TRUE または FALSE

に設定できます。新しいルールチェックを作成すると、 is_enabled プロパティはデフォルトで TRUE に設定され

ます。 report_drc を実行したときに DRC が使用されないようにするには、 is_enabled プロパティを FALSE に

設定します。

DRC ルールデックの作成

複数の関連する DRC チェックを一緒に実行できるように、 DRC ルールデックにグループ化できます。これには、

create_drc_ruledeck コマンドを使用して DRC ルールデックを作成し、 add_drc_ruledeck および

remove_drc_checks コマンドを使用して、 DRC を追加および削除します。 1 つの DRC ルールデックにユーザー

定義のチェックとあらかじめ定義されたチェックを含めることができます。次に、 myrules という DRC ルール

デックを作成し、 DRC を追加および削除する例を示します。

create_drc_ruledeck myrulesadd_drc_checks -ruledeck myrules {RAMW-1 RAMW-2 RAMW-3}remove_drc_checks {RAMW-2} -ruledeck myrules

注記: DRC の is_enabled プロパティが FALSE に設定されている場合、その DRC は report_drc を実行したとき

に DRC ルールデックの一部として実行されなくなります。 DRC ルールデックから DRC を削除するよりも、 DRC

をディスエーブルにする方が良い場合もあります。

カスタム DRC のレポート

ユーザー定義 DRC は、 report_drc コマンドを使用して、個別に、ほかのルールと一緒に、または DRC ルール

デックの一部として実行できます。次に、上記の例で定義された RAMW-1 ルールを個別に、ほかのルールと一緒に、

または DRC ルールデックの一部として実行する例を示します。

report_drc -check {RAMW-1}report_drc -check {RAMW-1 RAMW-2}report_drc -ruledecks myrules

report_drc でチェックが実行されるようにするには、ルールチェックの is_enabled プロパティを TRUE に設

定しておく必要があります。





DRC 説明スクリプト

DRC ルール名または DRC ルールのパターンを見たときに、そのルールの機能の説明が必要な場合があります。これ

には、 DRC オブジェクトのプロパティをレポートします。

次のスクリプト例は、入力して DRC ルールの検索パターンを指定することにより、各ルールの説明と重要度を表示

します。パターンに一致するルール場ない場合は、エラーメッセージが表示されます。

proc explain_drc { drcs } { package require struct::matrix set loop_drcs [get_drc_checks $drcs -quiet] if {$loop_drcs == {}} { puts " Error: $drcs does not match any existing DRC rule" return }struct::matrix drcsm

drcsm add columns 3 drcsm add row {DRC_ID SEVERITY DESCRIPTION} foreach drc $loop_drcs {

set description "\{[get_property DESCRIPTION [get_drc_checks $drc]]\}"set severity "\{[get_property SEVERITY [get_drc_checks $drc]]\}"set key "\{[get_property NAME [get_drc_checks $drc]]\}"drcsm add row "$key $severity $description"

} puts "[drcsm format 2chan]"; drcsm destroy}

Vivado 内に組み込まれている Tcl パッケージも多数あり、このスクリプト例では struct::matrix パッケージを使

用してサマリ表が見やすく表示されるようにしています。

次に、 explain_drc プロシージャの出力例を示します。

Vivado% explain_drc CFGBVS-1DRC_ID SEVERITY DESCRIPTION CFGBVS-1 Warning Missing CFGBVS and CONFIG_VOLTAGE Design Properties

Vivado% explain_drc CFGBVS-*DRC_ID SEVERITY DESCRIPTION CFGBVS-1 Warning Missing CFGBVS and CONFIG_VOLTAGE Design PropertiesCFGBVS-2 Critical Warning CFGBVS Design Property CFGBVS-3 Warning CONFIG_VOLTAGE Design Property CFGBVS-4 Critical Warning CFGBVS and CONFIG_VOLTAGE Design Properties CFGBVS-5 Critical Warning CONFIG_VOLTAGE Design Property CFGBVS-6 Critical Warning CONFIG_VOLTAGE with HP Config Banks CFGBVS-7 Warning CONFIG_VOLTAGE with Config Bank VCCO Vivado% explain_drc fooError: foo does not match any existing DRC rule





DRC の操作

DRC は、 Tcl のほかのオブジェクトと同様に、プロパティを変更できます。次のコマンドを使用すると、 DRC オブ

ジェクトのプロパティがリストされます。

Vivado% report_property [get_drc_checks RAMW-1]Property Type Read-only Visible ValueARCHITECTURES string* true trueCLASS string true true drc_checkDESCRIPTION string true true Block RAM Data Width CheckGROUP string true true RAMWHIERNAME string true true RAMB ChecksIS_ENABLED bool false true 1IS_USER_DEFINED bool true true 1MESSAGE string true trueMSG_ID int true true 1NAME string true true RAMW-1SEVERITY enum false true Advisory

注記: RAMW-1 DRC チェックの 2 つのプロパティ。 (IS_ENABLED および SEVERITY) は変更できます。 DRC チェッ

クオブジェクトのこれらのプロパティの値を変更するには、ほかのオブジェクトと同様に set_property コマン

ドを使用します。

RAMW-1 DRC チェックをディスエーブルにするには、次の Tcl コマンドを実行します。

Vivado% set_property IS_ENABLED false [get_drc_checks RAMW-1]

RAMW-1 DRC チェックの重要度を変更するには、次の Tcl コマンドを実行します。

Vivado% set_property SEVERITY {Critical Warning} [get_drc_checks RAMW-1]

これらのプロパティは、ビルトイン DRC ルールでも変更できます。ビルトイン DRC ルールをデフォルトにリセッ

トするには、次の Tcl コマンドを使用します。

Vivado% reset_drc_check [get_drc_checks]

注意: Vivado ではビルトイン DRC オブジェクトをディスエーブルにしたり重要度を下げたりすることが可能ですが、

予期しない結果が発生したり、デバイスを恒久的に破損する可能性があります。ビルトイン DRC オブジェクトを

ディスエーブルにしたり重要度を下げたりしないことを強くお勧めします。

DRC の実行に関する詳細は、『Vivado Design Suite ユーザーガイド : システムレベルデザイン入力』 (UG895) [参

照 7] を参照してください。





ザイリンクス Tcl Store

Vivado Design Suite では、ザイリンクスコミュニティ内で Tcl コードを配布および共有するためのリポジトリである

ザイリンクス Tcl Store が提供されています。ザイリンクス Tcl Store では、アプリ (複数の Tcl スクリプトをグループ

化したもの) やプラグインが提供され、これらのアプリおよびプラグインはザイリンクスコミュニティにより管理さ

れます。ザイリンクスユーザーであれば誰でも投稿できます。詳細は、ザイリンクス Tcl Store Wiki

(https://github.com/Xilinx/XilinxTclStore/wiki/Xilinx-Tcl-Store-Home) を参照してください。

ザイリンクス Tcl Store へのアクセス

ザイリンクス Tcl Store に関する情報は、ユーザーの $HOME/.Xilinx (Linux) または %APPDATA%/Xilinx

(Windows) エリアに保存されます。この保存された情報により、 Vivado リリースごとにユーザーがインストールした

アプリのリストが管理されます。これらのディレクトリは、オンラインのザイリンクス Tcl Store リポジトリから更

新およびアップデートされたアプリをキャッシュするためにも使用されます。

[Xilinx Tcl Store] ダイアログボックスを開く

[Xilinx Tcl Store] ダイアログボックスを開くには、 Vivado IDE を起動したときに表示される Getting Started ページで

[Xilinx Tcl Store] をクリックするか、メインメニューから [Tools] → [Xilinx Tcl Store] をクリックします。

注記: [Xilinx Tcl Store] ダイアログボックスを初めて開くときには、ザイリンクス Tcl Store の使用条件を示すダイア

ログボックスが表示されます。


図 11: [Xilinx Tcl Store] ダイアログボックスを開く


https://github.com/Xilinx/XilinxTclStore/wiki/Xilinx-Tcl-Store-Home




[Xilinx Tcl Store] ダイアログボックスには、 2 つのパネルがあります。

左側のパネルには使用可能なアプリがリストされ、右側のパネルには左側のパネルで選択したアプリに関する情報

が表示されます。各アプリに関して、次の情報が示されます。

• [Name]: アプリの名前。

• [Description]: アプリの簡単な説明。


図 12:ザイリンクス Tcl Store の使用条件


図 13: [Xilinx Tcl Store] ダイアログボックス





• [Revision]: アプリのリビジョン番号。

• [Required]: アプリを使用するのに低限必要な Vivado リリースバージョン (図 13 では Vivado 2014.1)。

• [Company]: アプリを提供および管理する企業の名前。

• [URL]: GitHub のアプリページへのハイパーリンク。ここからさまざまな proc のコードにアクセスできます。

• [Tcl Procs]: アプリに含まれる Tcl プロシージャと、各プロシージャの簡単な説明。

アプリのインストール

アプリをインストールするには、アプリ名の右側にある [Install] ボタンをクリックします。アプリをインストールす

ると、そのアプリで定義されているプロシージャが使用できるようになります。プロシージャは、アプリ名と企業

名から構成される特定の名前空間に取り込まれ、 Vivado のネイティブビルトインコマンドと同様に使用できます。

新しい Tcl コマンドは、自動的にヘルプ構造に登録されます。

図 14 に手順を示します。アプリをインストールする前に [Refresh] ボタンをクリックしてカタログを更新し、アプリ

の新バージョンがインストールされるようにすることをお勧めします (1)。 [Install] をクリックしてアプリをインス

トールします。


図 14: [Install] ボタン





アプリをインストールすると、プロシージャの名前がハイパーリンクになり、 [Install] ボタンが淡色表示されます。

図 15 では、 designutils アプリがインストールされています。

インストールされたアプリに関するヘルプの表示

アプリがインストールされると、各プロシージャに関するヘルプ情報を表示できるようになります。プロシージャ

の詳細なヘルプは、 2 つの方法で表示できます。ハイパーリンクの付いた proc 名をクリックすると、詳細なヘルプ

を表示するダイアログボックスが開きます。 proc 名を右クリックしても、ヘルプメニュー項目を含むコンテキスト

ウィンドウが開きます。 [Help] をクリックすると、選択した proc に対する埋め込み型ヘルプが開きます。また、 Tcl

コンソールに完全名前空間を含むプロシージャ名と -help コマンドラインオプションを入力しても、詳細ヘルプ

を表示できます。


図 15: インストールされた DesignUtils アプリ





図 16 は、 xilinx::designutils::write_template の詳細なヘルプを表示しています。

同じ詳細ヘルプは、 Tcl コンソールに次のように入力しても表示できます。

vivado% xilinx::designutils::write_template -help

注記: この proc の完全修飾子は xilinx::designutils::write_template で、 write_template のみではあり

ません。

インストールされたアプリに含まれる Tcl プロシージャへのアクセス

アプリをインストールしたら、そのアプリに含まれるすべてのプロシージャにコマンドラインから次の 2 つの方法

でアクセスできます。

• ::<company>::<app> 名前空間から。 Vivado IDE を起動すると、インストールされた各アプリに含まれるす

べてのプロシージャに対してラッパーが自動的に作成されます。

• アプリの完全名前空間修飾子 ::tclapp::<company>::<app> から (プロシージャが定義されている名前空間

)。


図 16: write_template ヘルプ





たとえば、 designutils アプリをインストールすると、ユーザー proc の write_template には次でアクセスできま

す。

vivado% ::xilinx::designutils::write_templatevivado% ::tclapp::xilinx::designutils::write_template

::tclapp::xilinx 名前空間ではなく ::xilinx 名前空間を使用する利点は、 Vivado で作成されるラッパーでは、

すべてのビルトイン Vivado コマンドに共通の -help、 -verbose、 -quiet などの多数のデフォルトコマンドライ

ンオプションがサポートされるということです。


Vivado% xilinx::designutils::write_template -helpxilinx::designutils::write_templateDescription: (User-written application)Generates a Verilog/VHDL stub or instantiation template for the current design in memory (current_instance)

Syntax: xilinx::designutils::write_template [-type <arg>] [-stub] [-template] [-language <arg>] [-verilog] [-vhdl] [-cell <arg>] [-file <arg>] [-append] [-return_string] [-usage] [-quiet] [-verbose]

Returns: template in the case of -return_string, otherwise 0 TCL_ERROR if error

Usage: Name Description ----------------------------- [-type] Type of template to create: stub or template Default: stub [-stub] Generate a stub (same as -type stub) [-template] Generate a template (same as -type template) [-language] Output language of the template: verilog or vhdl Default: verilog [-verilog] Verilog language (same as -language verilog) [-vhdl] VHDL language (same as -language vhdl) [-cell] Cell to generate template on. If not specified, runs on current_instance Default: current_instance [-file] Output file name Default: <module>.v or <module>.vhd [-append] Append to file [-return_string] Return template as string [-usage] Usage information [-quiet] Ignore command errors [-verbose] Suspend message limits during command execution

Categories:

Description:

Generates a Verilog/VHDL stub or instanciation template for the current design in memory (current_instance).





This command must be run on a synthesized or implemented design.

Example:

::xilinx::designutils::write_template -verilog -return_string

ソースコードへのアクセス

アプリまたは特定の proc のソースコードにアクセスするには、次の 2 つの方法があります。 [Details] ペインには、

GitHub への URL リンクが含まれます。このリンクをクリックすると、デフォルトブラウザーで GitHub 内のアプリ

ページが開きます。このページから、個別の proc のソースコードにアクセスできます。

アプリがインストールされると、 proc 名がハイパーリンクに変わります。ソースコードを表示するには、 proc 名を

クリックし、 [View Source Code] をクリックします。

注記: Tcl Store では、 proc の依存性は認識されません。 [Source] ウィンドウには選択した proc の内容のみが表示され、

依存する proc は表示されません。完全なアプリコードは、 GitHub のアプリの URL から参照できます。


図 17: GitHub アプリページへのハイパーリンク






図 18: proc ソースコード





Tcl Store での検索

Tcl Store 内を検索するには、アプリのリストの上の検索バーを使用します。検索は、 proc 名および proc サマリで実

行されます。アプリのリストには、検索結果に該当するものだけが表示されます。アプリを選択すると、検索に一

致する部分が白でハイライトされ、一致しない部分はグレーになります。


図 19:検索バー





ザイリンクス Tcl Store のサポート

特定のアプリまたは proc に対する問題をレポートさせるには、Tcl Store の GUI の右上の [Support on GitHub] をクリッ

クします。このリンクをクリックすると、デフォルトブラウザーが GitHub 内の Tcl Store サポートページに直接開き

ます。 GitHub サポートページには、問題をファイルするための追加情報が含まれます。


図 20: GitHub サポートページへのハイパーリンク





カタログの更新

アプリの GitHub へのリリースは、 Vivado Design Suite リリースとは同期していません。カタログを更新すると、新

版のアプリにアクセスできます。

カタログを更新するには、 [Xilinx Tcl Store] ダイアログボックスの左下にある [Refresh] ボタンをクリックします (1)。

これによりオンライン git リポジトリに対してすべてのアプリの新情報がクエリされ、カタログ更新の進捗状況を

示すボックスが表示されます (2)。その後アプリをインストールすると、オンラインリポジトリから新バージョン

がダウンロードされます。


図 21: カタログの更新





アプリのアップデート

カタログを更新すると、アプリのアップデートがオンラインリポジトリから入手可能である場合はそれが示されま

す。次の図では、 projutils アプリのバージョン 3.228 がインストールされています。カタログを更新すると、 [Update]

ボタンと [What's New] ハイパーリンクが表示され、新しいバージョンが入手可能であることがわかります。 [What's

New] ハイパーリンクをクリックすると、新しいバージョン 3.230 が入手可能であることが表示されます (図 22)。

この時点では、アプリはまだアップデートされていません。 projutils アプリのバージョンは、 [Update] ボタンをク

リックするまで 3.228 のままになります。

注記: アプリを一度アップデートすると、前のバージョンに戻すことはできません。


図 22: アプリの新しいバージョンを入手可能





アプリを新バージョンにアップデートするには、 [Update] ボタンをクリックします (1)。アプリのアップデートを

確認するダイアログボックス (2) が表示されます (図 23)。


図 23: アプリのアップデート





アップデートが完了すると、インストールされている projutils のバージョンが新版になります。


図 24: アップデートの確認





アプリのアンインストール

アプリをアンインストールするには、左側のパネルでアプリを選択し、右側の [Details] パネルの下部にある

[Uninstall Application] ハイパーリンクをクリックします (1)。アンインストールを確認するダイアログボックスが表

示されます (2)。

アプリをアンインストールすると、アプリに含まれているプロシージャは Tcl コンソールから使用できなくなりま

す。

カタログの更新のディスエーブル

アプリケーションによるファイアウォール外の情報のクエリが懸念される場合は、カタログの更新をディスエーブ

ルにできます。これにより、 Vivado からオンラインリポジトリにクエリが発行されなくなります。この場合、ユー

ザーは現在のバージョンのみを使用可能です。カタログの更新をディスエーブルにするには、スタートアップ

Vivado_init.tcl スクリプトに次の Tcl 行を追加します。これで、すべての Vivado セッションでカタログの更新

がディスエーブルになります。

vivado% set_param tclapp.enableGitAccess 0


図 25: アプリのアンインストール





カタログの更新をディスエーブルにすると、図 26 に示すように、 [Refresh] ボタンの代わりに「Internet access is not

available.」 (インターネットアクセスは使用できません) というメッセージが表示されます。

コード記述のガイドライン

ザイリンクス Tcl Store はオープンソースのリポジトリであり、内部および外部ユーザーが Tcl スクリプトを投稿し、

ザイリンクスコミュニティ内で共有できるようにします。スクリプトが重複していないことを確実にし、一貫性を

保持するため、ゲートキーピングコミティにより投稿が評価されます。このプロセスの詳細は、 Wiki ページ

(https://github.com/Xilinx/XilinxTclStore/wiki/Xilinx-Tcl-Store-Home) を参照してください。

このセクションでは、ザイリンクス Tcl Store にアプリを投稿する際に従う必要のあるコード記述ガイドラインを示

します。これらのガイドラインにより、スクリプトがザイリンクス Tcl Store の機構に準拠していること、すべての

アプリおよび Tcl スクリプトでプロシージャおよび変数の間に名前の競合がないことなどが確実になります。ただ

し、 Tcl Store に投稿する際のプロセスについては説明しません。投稿プロセスについては、 Wiki を参照してくださ

い。

ザイリンクス Tcl Store には、参考となるコード例として使用可能な Tcl スクリプトが多数あります。また、次のディ

レクトリにテンプレートアプリがあります。

<VIVADO_INSTALL>/data/XilinxTclStore/tclapp/mycompany/template/*


図 26: カタログの更新のディスエーブル






このテンプレートは、サンプルスクリプトと、新しいアプリで使用する必要のあるディレクトリ構造を示します。

このセクションでは、次のスクリプトを例として使用します。

<VIVADO_INSTALL>/data/XilinxTclStore/tclapp/mycompany/template/myscript1.tcl

このセクションのコード例では、アプリ名が template、アプリを提供および管理する企業の名前が mycompany

であるとします。

用語:

• ユーザープロシージャ : ユーザーが実行するプロシージャ。

• ヘルパープロシージャ : ユーザープロシージャでタスクを実行するためにバックグランドで使用されるプロ

シージャ。ヘルパープロシージャは、ユーザーによって直接実行されることはなく、ヘルプシステムには含ま

れません。

Vivado パッケージ

各アプリには、機能するために低限必要な Vivado バージョンがあります。 Tcl コードで必要な低限の Vivado

パッケージバージョンを指定すると、アプリでチェックされます。 Vivado パッケージ名のフォーマットは

1.<release> です。たとえば、 1.2016.1、 1.2016.2、 1.2016.3 のようになります。

アプリが機能するために Vivado 2016.1 が必要な場合、スクリプトの冒頭に次のコードを追加します。

package require Vivado 1.2016.1

アプリが Vivado 2016.3 に追加された機能を活用する場合は、次のコードを追加します。


必要な Vivado パッケージは、アプリが機能するために低限必要な Vivado リリースです。つまり、 Vivado の新しい

リリースで提供されている機能をサポートするためにアプリが変更された場合などを除き、 Tcl スクリプトで必要な

Vivado パッケージはアップデートするべきではありません。





アプリの名前空間

ザイリンクス Tcl Store 内では、Tcl スクリプトはアプリに含まれ、アプリ (例: template) は企業 (例: mycompany) に

より提供されています。アプリは、特定のタイプの機能を提供するコンテナーです。名前の競合を回避するため、

各アプリには独自の名前空間があります。アプリの完全な名前空間修飾子は、次のとおりです。

::tclapp::<company>::<app>

または

::tclapp::mycompany::template

次のようなコードがあるとします。

namespace eval ::tclapp::mycompany::template {namespace export my_command1}proc ::tclapp::mycompany::template::my_command1 { args } {}

このコードでは、名前空間 ::tclapp::mycompany::template にプロシージャ my_command1 を作成していま

す。 my_command1 はユーザーにより実行されるので、アプリの名前空間からエクスポートする必要があります。

これには、「namespace export my_command1」を使用します。

ユーザープロシージャとヘルパープロシージャ

Tcl スクリプトでは、複数のユーザースクリプトを定義できます。ユーザープロシージャは、ユーザーにより実行

される Tcl プロシージャ (コマンド ) です。前述のように、すべてのユーザープロシージャはアプリの名前空間から

エクスポートする必要があります。

ユーザープロシージャに加え、 Tcl スクリプトではヘルパープロシージャも定義できます。ヘルパープロシージャ

はユーザープロシージャでのみ使用され、ユーザーには使用できないようにする必要があるので、名前空間からエ

クスポートしません。どのプロシージャをユーザーがコマンドラインインターフェイス (スクリプトまたは Tcl コン

ソール) から実行できるようにするかをシステムで指定するには、プロシージャを名前空間からエクスポートするの

が唯一の方法です。

ユーザープロシージャがヘルパープロシージャを使用する場合、アプリの下にサブ名前空間を作成し、ユーザープ

ロシージャとヘルパープロシージャをその下に移動することをお勧めします。これにより、アプリ内のヘルパープ

ロシージャ間で名前の競合が発生するのを防ぐことができます。これは、さらにスクリプトを独自のヘルパープロ

シージャと共に追加する場合に特に重要です。





次のコードは、 Tcl コードに推奨される構造を示します。ユーザープロシージャはアプリの名前空間のすぐ下にあり

ますが、これはサブ名前空間 ::tclapp::mycompany::template::my_command1 の下に移動された元のプロ

シージャを呼び出すために使用されるラッパーです。

namespace eval ::tclapp::mycompany::template { namespace export my_command1}proc ::tclapp::mycompany::template::my_command1 { args } { # Calling the original code moved under the sub-namespace uplevel [concat ::tclapp::mycompany::template::my_command1::my_command1 $args]}eval [list namespace eval ::tclapp::mycompany::template::my_command1 {} ]proc ::tclapp::mycompany::template::::my_command1::my_command1 { args } { # Here is the code of the original proc}proc ::tclapp::mycompany::template::my_command1::helper1 { args } { # Here is the code of the helper proc}

注記: サブ名前空間 ::tclapp::mycompany::template::my_command1 は、その中にプロシージャを定義する

前に作成する必要があります。サブ名前空間を作成する構文は、リンターからのエラーメッセージを回避するため、

「eval [list namespace eval ::tclapp::mycompany::template::my_command1 {}]」とする必要があ

ります。

注記: コードを解読しやすくするため、上記のコードにはこのセクションの後の方で説明する必須のメタコメントは

含まれていません。

変数の競合

変数に関する重要な規則は、グローバル変数は禁止されているということです。ザイリンクス Tcl Store リンターは、

スクリプト内のグローバル変数をチェックし、グローバル変数が定義されているとエラーメッセージを表示します。

アプリに含まれる複数のプロシージャで変数を共有する必要がある場合は、その名前空間内で宣言します。これに

は、キーワード variable を使用して名前空間内で変数を作成します。このように作成した変数は、グローバル変

数のように使用できますが、その名前空間内のみで使用可能です。

次のコードでは、同じ名前空間に含まれるすべてのプロシージャで共有可能な変数 verbose を作成しています。こ

の変数は 0 に初期化されます。

namespace eval ::tclapp::mycompany::template { variable verbose 0}





プロシージャ内でこの変数にアクセスするには、プロシージャ内で変数をキーワード variable を使用して宣言し

ます。


proc ::tclapp::mycompany::template::::my_command1::my_command1 { args } { variable verbose # The variable verbose can be accessed here set verbose 1}proc ::tclapp::mycompany::template::my_command1::helper1 { args } { variable verbose # The variable verbose can be accessed here if {$verbose} { .. }}

注記:変数 verbose には、完全な名前空間修飾子を使用すれば、グローバル名前空間を含むどの名前空間からでも

アクセスできます。次に例を示します。

set ::tclapp::mycompany::template::verbose 1

メタコメント

Tcl スクリプト内のすべてのプロシージャには、必須のメタコメントを含める必要があります。この規則は、名前空

間からエクスポートされているユーザープロシージャとヘルパープロシージャの両方に適用されます。メタコメン

トが含まれていない場合、ザイリンクス Tcl Store リンターによりエラーメッセージが生成されます。エクスポート

されたすべてのプロシージャのメタコメントには、完全な情報が含まれていることが必要です。ヘルパープロシー

ジャのメタコメントは空にすることが可能ですが、メタコメントは宣言する必要があります。

メタコメントは、プロシージャの機能の簡単な説明、カテゴリ情報、プロシージャでサポートされるコマンドライ

ンオプションのリストなどの情報をシステムに提供します。

メタコメントは、プロシージャ定義とコードの初の行の間に挿入する必要があります。すべてのメタコメントが

必須です。

必須のメタコメントは、次のとおりです。

• Summary: プロシージャの機能のサマリ。複数行にできます。このサマリは、 [Xilinx Tcl Store] ダイアログボッ

クスにプロシージャの説明として表示されます。

• Argument Usage:プロシージャのコマンドライン引数のリスト。ヘルプシステムを構築するのに使用されます。

このガイドの別のセクションで、サポートされるフォーマットを示します。

• Return Value: プロシージャの戻り値。ヘルプシステムを構築するのに使用されます。

• Categories: アプリのカテゴリ。アプリをリストする Vivado ヘルプシステムのカテゴリを指定します。

「Categories:」の後にカテゴリをカンマで区切ってリストします。慣習として、初に xilinxtclstore

を指定し、その後にアプリ名を指定します。

次に、ユーザープロシージャに必要なメタコメントの例を示します。

proc ::tclapp::mycompany::template::my_command1 { args } { # Summary: Multi-lines summary of # what the proc is doing

# Argument Usage:





# [-verbose]: Verbose mode # [-file <arg>]: Report file name # [-append]: Append to file # [-return_string]: Return report as string # [-usage]: Usage information

# Return Value: # return report if -return_string is used, otherwise 0. If any error occur TCL_ERROR is returned

# Categories: xilinxtclstore, template

# The code for the proc starts below …}

注記: サブ名前空間にヘルパープロシージャと共に作成されたプロシージャ my_command1 ではなく、名前空間から

エクスポートされるユーザープロシージャに詳細なメタコメントを含める必要があります。

次に、ヘルパープロシージャのメタコメントの例を示します。すべてのメタコメントが定義されていますが、空で

す。

proc ::tclapp::mycompany::template::my_command1::lshift {inputlist} { # Summary : # Argument Usage: # Return Value: # Categories:

# The code starts below …}

スクリプトに含まれるすべての Tcl スクリプトにすべてのメタコメントを含める必要がありますが、詳細情報を含め

る必要があるのは、名前空間からエクスポートされるユーザープロシージャです。

コマンドライン引数のメタコメント

ユーザープロシージャのコマンドライン引数は、ユーザープロシージャ内でメタコメント Argument Usage を使

用して説明する必要があります。このメタコメントは、 <command> -help が実行されたとき、または [Xilinx Tcl

Store] ダイアログボックスでプロシージャのヘルプが表示されたときに、ヘルプシステムでメッセージを生成する

のに使用されます。次に例を示します。

# Argument Usage: # [-verbose]: Verbose mode # [-file <arg>]: Report file name # [-append]: Append to file # [-return_string]: Return report as string # [-usage]: Usage information

ヘルプシステムでこのメタコメント Argument Usage が使用され、次のメッセージが表示されます。

Syntax: xilinx::designutils::write_template [-verbose] [-file <arg>] [-append] [-return_string] [-usage] [-quiet]

Usage: Name Description -----------------------------





[-verbose] Verbose mode Default: 0 [-file] Report file name Default: None [-append] Append to file Default: 0 [-return_string] Return report as string Default: 0 [-usage] Usage information Default: 0 [-quiet] Ignore command errors

メタコメント Argument Usage は、Tcl プロシージャを呼び出す前の Vivado によるコマンドライン引数の前処理で

はないということに注意してください。ヘルプシステムで使用されるだけです。プロシージャの Tcl コードでコマ

ンドライン引数を処理する必要があります。

コマンドライン引数のないユーザープロシージャ

ユーザープロシージャにコマンドライン引数がない場合は、メタコメント Argument Usage は空にする必要があ

ります。次に例を示します。

proc ::tclapp::mycompany::template::my_command2 {} { # Summary : A one line summary of what this proc does

# Argument Usage:

# Return Value: # TCL_OK is returned with result set to a string


…}

コマンドライン引数のあるユーザープロシージャ

通常の Tcl プロシージャと同様、ユーザープロシージャの引数定義は、位置ベースにするか、 args 変数を使用して

引数の変数リストを指定します。

proc ::tclapp::mycompany::template::my_command2 { arg1 {optional1 ,} } {…}

または

proc ::tclapp::mycompany::template::my_command2 { args } {…}

どちらの場合でも、プロシージャで指定可能なコマンドライン引数のリストをメタコメント Argument Usage で

正しく定義するのは、開発者の責任です。システムでは、メタコメント Argument Usage からの引数のリストと実

際に引数定義が一致しているかはチェックされません。

メタコメント Argument Usage はヘルプメッセージに使用されるので、プロシージャで引数を渡すのにどちらの

形式を使用した場合でも、メタコメントをアップデートする必要があります。次に例を示します。

proc ::tclapp::mycompany::template::my_command2 { arg1 {optional1 ,} } {





# Summary : A one line summary of what this proc does # Argument Usage: # arg1 : A one line summary of this argument # [optional1=,] : A one line summary of this argument


# Categories: xilinxtclstore, template…}

または

proc ::tclapp::mycompany::template::my_command2 { args } { # Summary : A one line summary of what this proc does # Argument Usage: # arg1 : A one line summary of this argument # [optional1=,] : A one line summary of this argument


# Categories: xilinxtclstore, template…}

注記:可能な限り、位置ベースの引数ではなく args を使用してください。 args を使用した方が、コマンドライン

引数の順序に制限がないので、ユーザーが使用しやすいものとなります。プロシージャでサポートされるコマンド

ライン引数が 1 つか 2 つのみの場合は、位置ベースの指定方法を使用できますが、引数の順序は決まっており、

ユーザーにはどの順序で引数を指定すればよいかわからないので (ヘルプシステムではこの情報は含まれない)、

ユーザーには使いにくいものとなります。

メタコメント Argument Usage

これが、も複雑なメタコメントです。プロシージャでサポートされる必須またはオプションの各引数を、 1 行で指

定します。オプションの引数は、角かっこ ([ ]) で囲む必要があります。値を指定する必要のある引数には、リテラ

ルテキスト <arg> を追加し、値を指定する必要があることをユーザーに示し、説明部分に有効な値を説明する必要

があります。ユーザーがオプションの引数を指定しない場合に使用されるデフォルト値を指定することも可能です。

値のないオプションの引数 (フラグ) も可能です。コマンドラインでこれらのフラグを使用すると、値は True である

と想定され、アプリでそのオプションで指定される操作が実行されます。ただし、フラグ名に接頭辞 no_ が付いて

いる場合 (-no_cleanup など)、値は False であると想定され、デフォルトで実行される操作が実行されなくなりま

す。

位置指定引数を指定することもできます。位置指定引数は、対応するフラグ (-arg1 など) なしで値のみを指定する

ものです。

たとえば、次のようなメタコメントがあるとします。

# Argument Usage: # timingPath : mandatory name # [-append]: optional flag # -cell <arg>: mandatory argument with no default value





# [-template <arg> = stub]: optional argument with a default value. The default value is: stub

これにより、次のようなヘルプメッセージが生成されます。

Syntax: mycompany::template::mycommand [-append] -cell <arg> [-template <arg>] [-quiet] [-verbose] <timingPath> <-name>

Returns: template in the case of -return_string, otherwise 0 TCL_ERROR if error

Usage: Name Description ------------------------- [-append] optional flag Default: 0 -cell mandatory argument with no default value [-template] optional argument with a default value. The default value is: stub Default: stub [-quiet] Ignore command errors [-verbose] Suspend message limits during command execution <timingPath> mandatory

コマンドライン引数の実際の処理は、プロシージャ内でプログラムとして実行する必要があります。

注記: -append の使用はオプションで、デフォルト値は 0 です。コマンドラインで -append オプションを指定す

ると、システムから 1 が返されます。

スクリプト例

このセクションで示す例の完全なスクリプトは、次の場所にあります。

<XilinxTclStore>/tclapp/mycompany/template/myscript1.tcl


namespace eval ::tclapp::mycompany::template { # Export procs that should be allowed to import into other namespaces namespace export my_command1}

proc ::tclapp::mycompany::template::my_command1 { args } { # Summary: Multi-lines summary of # what the proc is doing

# Argument Usage: # [-verbose]: Verbose mode # [-file <arg>]: Report file name # [-append]: Append to file # [-return_string]: Return report as string # [-usage]: Usage information

# Return Value:





# return report if -return_string is used, otherwise 0. If any error occur TCL_ERROR is returned


uplevel [concat ::tclapp::mycompany::template::my_command1::my_command1 $args]}

# Trick to silence the lintereval [list namespace eval ::tclapp::mycompany::template::my_command1 {} ]

proc ::tclapp::mycompany::template::my_command1::lshift {inputlist} { # Summary : # Argument Usage: # Return Value: # Categories:





upvar $inputlist argv set arg [lindex $argv 0] set argv [lrange $argv 1 end] return $arg}

proc ::tclapp::mycompany::template::my_command1::my_command1 {args} { # Summary : # Argument Usage: # Return Value: # Categories: #------------------------------------------------------- # Process command line arguments #------------------------------------------------------- set error 0 set help 0 set filename {} set cell {} set returnString 0 while {[llength $args]} { set name [lshift args] switch -regexp -- $name { -cell - {^-c(e(ll?)?)?$} { set cell [lshift args] } -file - {^-f(i(le?)?)?$} { set filename [lshift args] if {$filename == {}} { puts " -E- no filename specified." incr error } } -append - {^-a(p(p(e(nd?)?)?)?)?$} { set mode {a} } -return_string - {^-r(e(t(u(r(n(_(s(t(r(i(ng?)?)?)?)?)?)?)?)?)?)?)?$} { set returnString 1 } -usage - {^-u(s(a(ge?)?)?)?$} { set help 1 } default { if {[string match "-*" $name]} { puts " -E- option '$name' is not a valid option. Use the -usage option

for more details" incr error } else { puts " -E- option '$name' is not a valid option. Use the -usage option

for more details" incr error } } } }





if {$help} { puts [format { Usage: my_command1 [-cell <arg>] - Cell to generate template on. If not specified, runs on current_instance [-file <arg>] - Output file name Default: <module>.v or <module>.vhd [-append] - Append to file [-return_string] - Return template as string [-usage|-u] - This help message

Description: Get information on a cell and generate a report

Example: tclapp::mycompany::template::my_command1 tclapp::mycompany::template::my_command1 -cell ila_v2_1_0 -return_string} ] # HELP --> return {} }

if {$error} { error " -E- some error(s) happened. Cannot continue" }

return -code ok "my_command1 result"}

Vivado コマンド linter を使用して、 Tcl スクリプトに対してザイリンクス Tcl Store リンターを実行できます。 Tcl スク

リプトのリストを引数として指定します。次に例を示します。

vivado% linter myscript.tclvivado% linter [glob -nocomplain *.tcl]

リンターで生成されるすべてのエラーを修正する必要があります。アプリを投稿するには、アプリに含まれるすべ

ての Tcl スクリプトがリンターによるチェックに合格することが必要です。

ザイリンクス Tcl Store への投稿

ザイリンクス Tcl Store にアプリを投稿することをお考えの場合は、次の Wiki ページを参照してください。


この Wiki には、さまざまな手順およびワークフローが詳細に説明されています。






Tcl スクリプト記述のヒント

いくつかの規則に従うことで、 Tcl スクリプトの実行時間と効率を向上できます。次に、 Vivado Design Suite で Tcl ス

クリプト機能を使用する際に、ランタイムを短縮し、メモリ使用量を抑えるための推奨事項を示します。

ネスト処理を使用したパフォーマンスの向上

Tcl コンソールから Tcl コマンドを実行すると、コマンドはまず Tcl インタープリターのレベルで処理されます。構

文エラーがない場合、コマンドはその後 C++ レベルで実行されます。コマンドで値が返される場合、 C++ コードに

より戻り値がソフトウェアのいくつかの層を介して Tcl インタープリターに送信されます。 Tcl インタープリターと

下位 C++ コードを行き来することが、実行時間に影響します。同じコマンド内でネスト処理を使用すると、ネスト

されたコマンドは C++ コードから直接呼び出され、コマンド全体が完了してから C++ コードから Tcl インタープリ

ターに戻ります。たとえば、次のようなコードがあるとします。

set nets [get_nets -hier]set pins [get_pins -of_objects $nets]

次のコードは、上記のコードよりも高速に処理されます。

set pins [get_pins -of_objects [get_nets -hier]]

これは、初のコードでは中間 Tcl 変数 nets が作成されるからです。

ただし、これらの変数の結果がコードのほかの部分で再利用される場合、中間 Tcl 変数を作成する方が有利なことも

あります。

オブジェクトのキャッシュ

オブジェクトまたはオブジェクトのリストを Tcl 変数にキャッシュし、再利用します。

たとえば、同じネットのリストをスクリプトで複数回使用する場合は、同じクエリを繰り返し実行するのは効率的

ではありません。 Vivado ツールの Tcl コマンドは効率的に実行されますが、 Tcl クエリを実行するたびに Tcl イン

タープリターとアプリケーションの下位 C++ コードの間を行き来することになります。この C++/Tcl のアクセスに

時間がかかるので、できる限り避けるようにします。

Vivado ツールの異なるフィルター機能をできる限り利用します。効果的な検索パターン、 -of_objects オプショ

ン、 -filter オプション、および filter コマンドを使用することで実行時間を短縮できます。これらの機能はア

プリケーションの下位にインプリメントされており、実行時間およびメモリの点で非常に効率的です。

クエリの結果をキャッシュして、そのオブジェクトのリストに対して filter コマンドを実行してオブジェクトの

サブリストを作成できます。また、インメモリデザインにアクセスせずに、標準 Tcl コマンドを使用して Tcl 変数に

代入された結果を解析できます。

set allCells [get_cells * -hier]lsort $allCells ; # Returns a sort ordered list of all cellsfilter $allCells {IS_PRIMITIVE} ; # Returns only the primitive cellsfilter $allCells {!IS_PRIMITIVE} ; # Returns non-primitive cells





オブジェクト名と NAME プロパティ

デザインオブジェクトを必要とする Tcl コマンドと、文字列入力を必要とする Tcl コマンドがあります。 Vivado

Design Suite では、文字列引数を必要とする Tcl コマンドであっても、デザインオブジェクトを直接渡すことができ

ます。この場合、デザインオブジェクトの階層名が文字列として Tcl コマンドに渡されます。オブジェクトの

NAME プロパティを取得して Tcl コマンドに渡す必要はありません。

たとえば、次の regexp コマンドでは、 2 つの if 文は同等で、オブジェクトの名前が渡されます。

if {[regexp {.*enable.*} $MyObject]} { ... }if {[regexp {.*enable.*} [get_property NAME $MyObject]]} { ... }

上記の例では、初のコードの方が読みやすいだけでなく、オブジェクトのプロパティを取得する必要がないので

実行時間も短くなります。 2 番目の例では get_property コマンドにより、オブジェクトプロパティを取得するた

め、 Tcl インタープリターと下位 C++ アプリケーションコードの間にアクセスが発生します。これを複数のオブ

ジェクトに対してループで実行すると、 Tcl スクリプトの実行時間が大幅に増加します。

get_property およびリストの並べ替え

get_property で返されるエレメント (文字列またはオブジェクト ) のリストは、オブジェクトの入力リストに基づ

いて並べ替えられます。エレメントの数も同じになります。このプロパティは、複数リストに対して Tcl コマンドの

foreach で繰り返すことができます。

非効率なコード :

set cells [get_cells -hier -filter {...}]foreach cell $cells { set loc [get_property LOC $cell] ...}

このコードの場合、 get_property LOC $cell コマンドが $cells コレクション内のセルごとに実行されます。

効率的なコード :

set cells [get_cells -hier -filter {...}]foreach cell $cells loc [get_property LOC $cells] { ...}

このコードの場合、 get_property LOC $cells コマンドが一度しか実行されないので、長いオブジェクトのリ

ストの実行時間がかなり改善されます。これは、 get_property で返されたリストに Tcl リストの $cells と同じ

数のエレメントが含まれ、返されたエレメントが入力リストと同じ順番だからです。

オブジェクトのリストのフォーマット

get_* コマンドから返されたリストはフォーマットされておらず、 stdout にスペースで区切られて 1 行で表示さ

れます。この例を次に示します。

get_cellsA B clk_IBUF_inst rst_IBUF_inst din0_IBUF_inst din1_IBUF_inst dout0_OBUF_inst dout1_OBUF_inst dout2_OBUF_inst dout3_OBUF_inst clk_IBUF_BUFG_inst





このフォーマットされていないリストでは、 Tcl コンソールおよび Vivado IDE で何が返されたかを確認するのが困難

です。リストの各アイテムを個別の行に表示するには、次のようにコマンドを join コマンドにネストし、改行文

字 \n を追加します。

join [get_cells] \nABclk_IBUF_instrst_IBUF_instdin0_IBUF_instdin1_IBUF_instdout0_OBUF_instdout1_OBUF_instdout2_OBUF_instdout3_OBUF_instclk_IBUF_BUFG_inst

get_* コマンドで返されるリストは、 join コマンドでは変更されません。

注記: オブジェクトの Vivado コレクションを文字列に変換した場合、文字列表現にすべてのオブジェクトが含まれな

いことがあります。コレクションの文字列表現に含まれるオブジェクトの大数は、

tcl.collectionResultDisplayLimit パラメーターで指定します。デフォルトは 500 です。詳細は、「コレク

ションと文字列表現」を参照してください。

Vivado Tcl コマンドをオプションで検索

次のプロシージャ findCmd を使用すると、 Vivado Design Suite のすべての Tcl コマンドの構文が検索され、指定のオ

プションをサポートするコマンドがリストされます。

proc findCmd {option} {foreach cmd [lsort [info commands *]] {catch {if {[regexp "$option" [help -syntax $cmd]]} {puts $cmd

} }

} } ; # End proc

たとえば、 -return_string オプションをサポートする Vivado ツールコマンドを検索するには、次のコマンドを

使用します。

findCmd return_string

効率的なコードの記述

実行時間を短縮する方法の 1 つに、コンテナーに含まれる各要素に対してループ内のコマンドを実行するのではな

く、コンテナーを作成してコマンドをコンテナー全体に対して実行する方法があります。次の例はこれを示してお

り、「カスタムデザインルールチェック (DRC) の作成」の例と似ています。

非効率なコード :

foreach bram [get_cells -hier -filter {PRIMITIVE_SUBGROUP == bram}] {set bwidth [get_property WRITE_WIDTH_B $bram]if { $bwidth > 36} {

highlight_object -color red [get_cells $bram]





}; # End IF}; # End FOR

効率的なコード :

foreach bram [get_cells -hier -filter {PRIMITIVE_SUBGROUP == bram}] {set bwidth [get_property WRITE_WIDTH_B $bram]if { $bwidth > 36} {

lappend bram_list $bram}; # End IF

}; # End FORhighlight_object -color red [get_cells $bram_list]

上記のコードをさらに短く効率的に記述するには、 get_cells コマンドにフィルターを適用します。これにより、

個別のチェックを含む foreach ループを実行する必要がなくなりますが、多少複雑なフィルターが必要になりま

す。

highlight_object -color red [get_cells -hier -filter {PRIMITIVE_SUBGROUP == bram && WRITE_WIDTH_B > 36}]

ユーザー入力の取得

従来の tclsh シェルの場合、ユーザー入力は通常 stdin チャネルを使用して取り込まれます。次に例を示します。

gets stdin answer

Vivado IDE では、 Tcl コードを異なる環境で実行できますが、 stdin チャネルとは互換性のないことがほとんどで

す。スクリプトがローカルシェルの Vivado Tcl モードでのみ実行されるとわかっている場合を除き、ユーザー入力

を取得するのに stdin は使用できません。

ユーザー入力は、通常スクリプトのビヘイビアーを変更したり、パラメーターの値を設定したりするために使用さ

れます。この際、 stdin からの情報取得は信頼できず、エラー (タイプミス、間違った値など) になる可能性が高く

なります。

スクリプトにカスタム値を提供する際には、 Tcl スクリプトから簡単に読み出すことのできるコンフィギュレーショ

ンファイルを使用することをお勧めします。コンフィギュレーションファイルは、 Tcl 変数のリストと同じように

単純にでき、次のコマンドを使用してスクリプトにインポートできます。

source <configuration_file>

このようなコンフィギュレーションファイルは、 Vivado IDE をバッチモードで実行している場合か、リモートマシ

ン (LSF など) を使用している場合に使用できます。




付録 A

その他のリソースおよび法的通知

ザイリンクスリソース

アンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照して

ください。

ソリューションセンター

デバイス、ツール、 IP のサポートについては、ザイリンクスソリューションセンターを参照してください。トピッ

クには、デザインアシスタント、アドバイザリ、トラブルシュートヒントなどが含まれます。

Documentation Navigator およびデザインハブ

Xilinx Documentation Navigator (DocNav) を使用するとザイリンクスの資料、ビデオ、およびサポートリソースにアク

セスして情報をフィルター、検索できます。 Xilinx Documentation Navigator を開くには、次のいずれかを実行しま

す。

• Vivado IDE で [Help] → [Documentation and Tutorials] をクリックします。

• Windows で [スタート ] → [すべてのプログラム] → [Xilinx Design Tools] → [DocNav] をクリックします。

• Linux コマンドプロンプトに「docnav」と入力します。

ザイリンクスデザインハブには、資料やビデオへのリンクがデザインタスクおよびトピックごとにまとめられてお

り、これらを参照することでキーコンセプトを学び、よくある質問を解決できます。デザインハブにアクセスする

には、次のいずれかを実行します。

• Xilinx Documentation Navigator で [Design Hubs View] タブをクリックします。

• ザイリンクスウェブサイトのデザインハブページを参照します。

注記: Documentation Navigator の詳細は、ザイリンクスウェブサイトの Documentation Navigator ページを参照してく

ださい。

注意: Xilinx Documentation Navigator からは、日本語版は参照できません。ウェブサイトのデザインハブページの一

部は翻訳されており、日本語版が提供されている場合はそのリンクも追加されています。



https://japan.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=docnav

https://japan.xilinx.com/support

https://japan.xilinx.com/support/solcenters.htm


付録 A: その他のリソースおよび法的通知

参考資料

1. 『Vivado Design Suite Tcl コマンドリファレンスガイド』 (UG835)

2. 『Vivado Design Suite ユーザーガイド : 入門』 (UG910)

3. 『Vivado Design Suite ユーザーガイド : 制約の使用』 (UG903)

4. 『ISE から Vivado Design Suite への移行ガイド』 (UG911)

5. 『Vivado Design Suite ユーザーガイド : デザインフローの概要』 (UG892)

6. 『Vivado Design Suite ユーザーガイド : Vivado IDE の使用』 (UG893)

7. 『Vivado Design Suite ユーザーガイド : システムレベルデザイン入力』 (UG895)

8. Tcl Developer Xchange

9. Vivado Design Suite の資料

トレーニングリソース

ザイリンクスでは、この資料に含まれるコンセプトを説明するさまざまなトレーニングコースおよび QuickTake ビデ

オを提供しています。次のリンクから関連するトレーニングリソースを参照してください。

1. Vivado デザインツールフロートレーニングコース

2. トレーニングコース : Vivado Design Suite を使用した FPGA の設計 1




6. Vivado Design Suite QuickTake ビデオチュートリアル

7. Vivado Design Suite QuickTake ビデオ: Vivado IP インテグレーターを使用した Zynq デバイスの設計

8. Vivado Design Suite QuickTake ビデオ: Vivado Design Suite でパーシャルリコンフィギュレーションを実行

9. Vivado Design Suite QuickTake ビデオ: Vivado Design Suite でのリビジョン管理の使用

10. Vivado Design Suite QuickTake ビデオ: デザインフローの概要

11. Vivado Design Suite QuickTake ビデオ: プロジェクトを作成せずにバッチファイルを使用する方法 (非プロジェク

トフロー )

12. Vivado Design Suite QuickTake ビデオ: プロジェクトバッチフローの使用


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug835-vivado-tcl-commands.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug910-vivado-getting-started.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug903-vivado-using-constraints.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug911-vivado-migration.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug892-vivado-design-flows-overview.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug893-vivado-ide.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2017.4;d=ug895-vivado-system-level-design-entry.pdf

www.tcl.tk

www.tcl.tk

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=vivado+docs

https://japan.xilinx.com/training/vivado/vivado-design-suite-tool-flow.htm

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=training;d=designing-fpgas-vivado-design-suite-1.html




https://japan.xilinx.com/cgi-bin/docs/ndoc?t=vivado+videos

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=targeting-zynq-using-vivado-ip-integrator.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=partial-reconfiguration-in-vivado.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=vivado-design-suite-revision-control.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=vivado-design-flows-overview.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=using-the-non-project-batch-flow.html

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=video;d=using-the-project-batch-flow.html



付録 A: その他のリソースおよび法的通知

お読みください: 重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ ) に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適

用される法律が許容する大限の範囲で、 (1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提供

され、ザイリンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこれ

らに限られません)、すべての保証および条件を負わない (否認する ) ものとします。また、 (2) ザイリンクスは、本情報 (貴殿または

貴社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負わな

い (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害に

は、直接、間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信用の

損失、その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可能で

あったり、ザイリンクスがそれらの可能性について助言を受けていた場合であったとしても同様です。ザイリンクスは、本情報に

含まれるいかなる誤りも訂正する義務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負いま

せん。事前の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示してはなりません。一

定の製品は、ザイリンクスの限定的保証の諸条件に従うこととなるので、 https://japan.xilinx.com/legal.htm#tos で見られるザイリンク

スの販売条件を参照してください。 IP コアは、ザイリンクスが貴殿または貴社に付与したライセンスに含まれる保証と補助的条件

に従うことになります。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプリケー

ションに使用するために、設計されたり意図されたりしていません。そのような重大なアプリケーションにザイリンクスの製品を

使用する場合のリスクと責任は、貴殿または貴社が単独で負うものです。 https://japan.xilinx.com/legal.htm#tos で見られるザイリンク

スの販売条件を参照してください。

自動車用のアプリケーションの免責条項

オートモーティブ製品 (製品番号に「XA」が含まれる ) は、 ISO 26262 自動車用機能安全規格に従った安全コンセプトまたは余剰性

の機能 ( 「セーフティ設計」 ) がない限り、エアバッグの展開における使用または車両の制御に影響するアプリケーション ( 「セー

フティアプリケーション」 ) における使用は保証されていません。顧客は、製品を組み込むすべてのシステムについて、その使用

前または提供前に安全を目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品

を使用するリスクはすべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うものとします。

© Copyright 2012-2017 Xilinx, Inc. Xilinx、 Xilinx のロゴ、 Artix、 ISE、 Kintex、 Spartan、 Virtex、 Vivado、 Zynq、およびこの文書に含

まれるその他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。すべてのその他の商標は、それぞれ

の保有者に帰属します。

この資料に関するフィードバックおよびリンクなどの問題につきましては、 [email protected] まで、または各ページの

右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語で

入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは受

け付けておりません。あらかじめご了承ください。


mailto:[email protected]

https://japan.xilinx.com/legal.htm#tos

https://japan.xilinx.com/legal.htm#tos



Vivado Design Suite - Xilinx...Vivado Design Suite ユーザーガイド Tcl...

Documents

Transcript of Vivado Design Suite - Xilinx...Vivado Design Suite ユーザーガイド Tcl...

Vivado Design Suite - Xilinx...Vivado Design Suite ユーザー ガイド Tcl...

Documents

Transcript of Vivado Design Suite - Xilinx...Vivado Design Suite ユーザー ガイド Tcl...

Vivado Design Suite - Xilinx...Vivado Design Suite ユーザーガイド Tcl...

Transcript of Vivado Design Suite - Xilinx...Vivado Design Suite ユーザーガイド Tcl...