Xilinx VivadoでSVNを使用していますか?


13

新しいプロジェクトでVivadoを使用すると述べたので、プロジェクトファイルをSVNの下に配置したいと考えています。

Vivadoは、プロジェクト名(proj1など)の下にすべてのプロジェクトファイルを作成するようです。

/<path to the project>/proj1/
                            proj1.xpr
                            proj1.srcs/
                                       constrs_1/
                                                new/
                                                    const1.xdc
                            proj1.runs/
                            proj1.data/
                            proj1.cache/

私の質問は、XDCおよびXPRファイル以外のSVNに置く必要があるファイルは何ですか?


1
なぜあなたはそれらのすべてを必要としないと思いますか?
グレイディプレーヤー

6
ここでの意味がわかりません。Vivadoは、大量のファイルを作成しますが、これらのファイルは生成されるため、制御する必要はありません。ソースファイルはどこかにあります。Vivadoにとって重要なファイルを保存するだけです。
-FarhadA

入力はソースコードのみであるため、SVNの下に置く唯一のファイルだと思います。しかし、私はちょうど推測、それを使ったことがない
clabacchio

クリーンなオプションはありますか?あなたには、すべてをチェックし清掃してください可能性があります。
グラディプレーヤー

2
Vivadoプロジェクトを再生成するTCLスクリプトを作成しています。そして、それをバージョン管理下に置きます。(makeを使用して)プロジェクトをビルドすると、Xilinxが必要とするファイルが作成されます。これにより、ザイリンクスのプロジェクトディレクトリとファイル全体をチェックインする必要がなくなります。
-vermaete

回答:


6

ザイリンクスはこれに対処するためにYouTubeビデオ(ため息)を作成します。ビデオへのリンクはこちら

http://www.xilinx.com/training/vivado/vivado-version-control-overview.htm

ビデオの概要は次のとおりです(8分)

始める前に

フルコントロールが本当に必要な場合、ザイリンクスはGUIを完全に放棄し、コマンドラインですべてを実行することをお勧めします。そうすれば、ソースとそうでないものを把握できます。

そうでない場合、ザイリンクスは、Vivadoプロジェクトがバージョン管理用に設計されていないことを認識します。プロジェクト全体をチェックインしないでください。しかし、ヒントを読んでください...

ベースライン

もちろん、Vivadoツール以外で作成したものはすべてチェックインする必要があります。

以下のファイルをチェックインします

*.v, *.vh, *.vhdl, *.edif  - HDL and Netlist
*.xdc - Constraints
*.xci - IP Core
*.bd  - IP Integrator Block Diagram
*.xmp - Embedded Subsystem
*.sgp - System Generator Subsystem
*.bmm
*.cdc - Chipscope
*.elf
*.mem

IPブロック

IPブロックを使用する場合は、一意のフォルダーにIPを生成し、すべてをチェックインします。

チェックポイント

すべてを実行せずにフローの一部を再実行できるようにする場合は、チェックポイントファイルをチェックインします。

*.dcp - Design Checkpoints

私の補遺

ザイリンクスツールが効率的である場合、dcpファイルをチェックインすることはお勧めしませんが、実行に非常に長い時間がかかるため、バージョン管理システムのコストが高くなります。

このビデオでは、Vivadoプロジェクトファイル(* .xpr)について不平を言っていないので、ここに私の提案を示します。

*.xpr
*.data/*/fileset.xml
*.data/*/runs.xml

ザイリンクスが推奨する代替策(実際にはハックであり、バージョン管理に適していない)はFile -> Write Project Tcl、コミットするたびにコマンドを実行し、そのTCLファイルをバージョン管理にコミットすることです。ローカルフォルダーを更新する場合、そのTCLファイルを再実行して、すべてのプロジェクトファイルを作成する必要があります。うん


素晴らしい、それは本当に役に立ちました。私はもはやSVNではなくGITを使用していますが、これは適切なファイルをリポジトリに取り込むのに役立ちます。
FarhadA

1
私はtclファイルを使用していますが、実際にはうまく機能します。tclスクリプトは、ファイルがプロジェクトに追加された場合にのみ更新する必要があり、通常、すべてのファイルが入ったときにtclを生成します。
スタンリ14

プロジェクトが変更されるたびにVivadoが自動的にTCLファイルを作成し、TCLファイルをxprファイルではなく「プロジェクト」ファイルとして読み込む場合、TCLソリューションが理想的です。言い換えると、ザイリンクスがxprファイルを削除して、tclファイルに置き換えた場合です。
マークラカタ14

xprファイルのコミットにはわずかな問題があります
。Vivado

3

Vivado 2014.1では、.tclスクリプトを使用してプロジェクトを再生成できます。

これを行うには、プロジェクトを開いた状態で、[ファイル]-> [プロジェクトtclの書き込み]に移動します。

基本プロジェクト

通常、ソースと.tclスクリプトはプロジェクトディレクトリ以外の場所に保存します。プロジェクト内で生成されたxilinx IPコアは、コアを右クリックして[IPのコピー]を選択することにより、他の場所にコピーできます。元を削除します。tclスクリプトが生成されると、これらのファイルへの相対リンクが作成されます。これは通常、私のディレクトリ構造は次のようになります。

base_project/
 srcs/
  project.v
 ip/
  ip1/
   ip1.xml
   ip1.xci
 genproject.tcl

IP .xmlおよび.xciファイルのみをコミットする必要があります。(そして、技術的には、これでさえ必要ではありません。最後の注意事項を参照してください)。

これがgitにコミットされます。project.xprまたはプロジェクトディレクトリがないことに注意してください。

を実行するgenproject.tclと、プロジェクト用の別のディレクトリが作成されます。

base_project/
 srcs/
 ip/
 genproject.tcl
 projectdir/
  project.runs/
  project.cache/
  project.xpr

この新しいフォルダは完全に使い捨てです。この構造を作成するには、次の方法でtclスクリプトを変更します。

最初の3行を次のように変更します。

# Set the reference directory for source file relative paths (by default the value is script directory path)
set origin_dir [file dirname [info script]]

# Set the directory path for the original project from where this script was exported
set orig_proj_dir "[file normalize "$origin_dir/projectdir"]"

# Create project
create_project project $projectdir/project

これにより、新しいプロジェクトディレクトリとそのディレクトリに新しいプロジェクトが作成されます。

次に、正しい場所を指すようにパスを変更します。スクリプト内の他の場所でこれらのパスを変更する必要がある場合があります。

# Set 'sources_1' fileset object
set obj [get_filesets sources_1]
set files [list \
 "[file normalize "$origin_dir/srcs/project.v"]"\
 "[file normalize "$origin_dir/ip/ip1/ip1.xci"]"\
]
add_files -norecurse -fileset $obj $files

この回答に見られるように、IPコアのデザインランも変更します

.wcfgファイルは、ipおよびsrcsと同様の方法で含めることができます。

ここで、より単純なプロジェクト(ソースとIPのみが含まれ、ブロック図は含まれません)の処理が終了します。ブロック線図データを保存するには、以下も実行する必要があります。

ブロック図プロジェクト

ブロック図を開いた状態でブロック図を保存するには、[File]-> [Export]-> [Block Diagram to Tcl]を選択し、他のtclファイルと同じディレクトリに保存します。

次にGenerate_Wrapper.tcl、ブロック図ラッパーファイルを作成するスクリプトを作成したので、手動で行う必要はありません。project / project.srcsフォルダーはbdデータの保存に使用されますが、bdはtclスクリプトに保存されるため、完全に使い捨てです。これを他の2つで保存します。

set origin_dir [file dirname [info script]]

make_wrapper -files [get_files $origin_dir/project/project.srcs/sources_1/bd/design_1/design_1.bd] -top
add_files -norecurse -force $origin_dir/project/project.srcs/sources_1/bd/design_1/hdl/design_1_wrapper.v
update_compile_order -fileset sources_1
update_compile_order -fileset sim_1

最後に、genproject.tclブロック線図とラッパーを生成するために次の行を追加します。

source $origin_dir/Create_bd.tcl
source $origin_dir/Generate_Wrapper.tcl
regenerate_bd_layout

ソースのないプロジェクト(ブロック図のみ)の場合、gitコミットは次のようになります。

base_project/
 Generate_Wrapper.tcl
 Create_Bd.tcl
 genproject.tcl

すべてを生成するには、を実行しgenproject.tclます。

特に効率的な場合は、これらすべてを1つにまとめることもできますが、まだ説明していません。

カスタムコンポーネント:コンポーネントプロジェクト

カスタムコンポーネントの作成に関するもう1つの簡単なメモ。component.xmlがある場合は、tclソースリストに追加します。

  "[file normalize "$origin_dir/component.xml"]"\

そして、次のセクションも追加します。

set file "$origin_dir/component.xml"
set file [file normalize $file]
set file_obj [get_files -of_objects [get_filesets sources_1] [list "*$file"]]
set_property "file_type" "IP-XACT" $file_obj

これには、簡単なカスタマイズのためのプロジェクトへのコンポーネント設計が含まれます。

カスタムコンポーネント:コンポーネントの参照

次のように、カスタムコンポーネントリポジトリパスを指定できます。

# Set IP repository paths
set obj [get_filesets sources_1]
set_property "ip_repo_paths" "[file normalize "$origin_dir/path/to/repository"]" $obj

リポジトリフォルダーには、.xmlファイルを含む個々のフォルダーがあります。したがって、.xmlを含むフォルダーではなく、そのフォルダーの親を参照しています。例えば:

repository/
 component1/component1.xml
 component2/component2.xml

これらのtclスクリプトをどのように実行しますか?

Vivadoを開き、プロジェクトを開かずに、[ツール]-> [TCLスクリプトの実行]を選択して、スクリプトに移動します。

追加のTCLノート

Vivadoで実行するすべてのコマンドは、tclコンソールにtclコマンドとして表示されます。たとえば、GUIを使用して新しいザイリンクスIPを生成すると、tclコンソールに次のように表示されます。

create_ip -name floating_point -vendor xilinx.com -library ip -module_name floating_point_0
set_property -dict [list CONFIG.Operation_Type {Fixed_to_float} CONFIG.A_Precision_Type {Custom} CONFIG.C_A_Exponent_Width {38} CONFIG.C_A_Fraction_Width {0} CONFIG.Result_Precision_Type {Custom} CONFIG.C_Result_Exponent_Width {8} CONFIG.C_Result_Fraction_Width {16} CONFIG.Flow_Control {NonBlocking} CONFIG.Has_ARESETn {true}] [get_ips floating_point_0]

これはいくつかのことを意味します。

  • xilinx IPコアを保存する必要さえありません-いったんそれらが希望通りになったら、コマンドをtclスクリプトにコピーし、ip /をコミットする必要はもうありません。

  • -module_nameの後に-dir引数を使用してIPディレクトリを指定し、任意の場所に配置します(デフォルトではproject.srcsにあります)。

  • GUIで行うほとんどの操作はtclで行うことができます。xilinxがどのように機能するかを確認する最も簡単な方法は、GUIでそれを行い、その後TCLコンソールの内容を確認することです。

  • この膨大なPDFには、すべてのvivado tclコマンドの詳細が記載されています。


2

Vivadoでバージョン管理システムを使用する方法を説明するザイリンクストレーニングビデオがあります。基本的に、ファイルのリストは、使用している機能によって異なります。

(vermaeteのように)スクリプト化されたアプローチを使用する場合、Vivadoですべての中間/一時ファイルを個別のディレクトリに書き込み(ここを参照)、簡単に分離できます。

それ以外の場合は、Vivadoでビルドフォルダーをクリーンアップできます。残っているものはすべてバージョン管理下に置かれる可能性があります。


1
おかげで、調べてみると、ザイリンクスが非常に高価なツールを思い付くことができますが、それを使用してリビジョン管理の適切なサポートを提供することさえできません。
-FarhadA

1
ザイリンクスフォーラム(2009 IIRC以降)で興味深いコメントがありました。このツールはハードウェアエンジニア向けです。また、ハードウェアエンジニアは、リビジョン管理についても気にもせず、気にしません。しかし、私は態度が変わって、これらのツールを使用するソフトウェアエンジニアが増えていると思います。そのため、改訂管理は過去よりも重要になりました。
hli

2
まあ、それは今までそれらの言葉を言った純粋なis辱です。HWエンジニアはさまざまなタイプのリビジョン管理を使用し、多くのツールがそれをサポートし、多くのエンジニアは標準RCを使用してそれを行い、他のエンジニアは組み込みRCのMentor HDLデザイナーなどのツールを使用します。悲しいことに、ザイリンクスやアルテラなどのFPGAベンダーはこれらの問題を気にしていないようです。それが主な問題です。
-FarhadA

1

ザイリンクスフォーラムでこのスレッドをご覧ください。

http://forums.xilinx.com/t5/Implementation/What-files-to-put-under-revision-control-for-consistent-build/td-p/174232


2
その議論から興味深いコンテンツを含めることができれば、あなたの答えははるかに役立ちます。また、最終的にリンク切れになるまで生き残るからです(フォーラムではアーカイブされる可能性があります)
clabacchio
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.