ATNDのページはこちらです。
第0回に続き、今回も発表させていただきました。発表資料を置いておきます。
「コマンドラインでFPGAプロジェクト～Quartus, SOPC Builder編～」
この発表のコマンドラインの使い方 (コマンドラインというかフロー自体かな?)、実は@s_osafuneさんの発表内容に関連した問題があります。
.sopcファイルからsopc_builderコマンドなり、GUIのSOPC Builderで.v等をgenerateすると、実行するたびにSYSIDが変化してしまいます。
開発中で試行錯誤中はSYSIDが変化していくのが当然なので問題ありません。
ですが、バージョン管理システムに追加して、複数のユーザやPCで作業しようとすると、問題が顕在化します。
同じ.sopcファイルを元にしていても、論理合成はAさん、ファームウェアのビルドはBさん、といった組み合わせで動かせないのです。
開発中で試行錯誤中はSYSIDが変化していくのが当然なので問題ありません。
ですが、バージョン管理システムに追加して、複数のユーザやPCで作業しようとすると、問題が顕在化します。
同じ.sopcファイルを元にしていても、論理合成はAさん、ファームウェアのビルドはBさん、といった組み合わせで動かせないのです。
かといって、SOPC Buillderが生成する.vファイル等をまとめてバージョン管理等で保持するのもうまく行きません。SOPC Buillderが生成するファイルに絶対パスが含まれることがあるからです。そのままバージョン管理システムに追加すると、非常に使いづらいものになります(ワーキングコピーを最初に追加した人と同じ絶対パスに配置しないと動かない)。
では、どうするのがよいのか?
私の今の考えでは、GitHub等で公開する場合、複数のユーザが参照しうるが、ユーザ間で共同作業しない、という前提で、.sopcファイルのみをバージョン管理対象とするのがベター、と考えています。
cloneしたワーキングコピーそれぞれで、SOPC構成のgenerate～ファームウェアビルドまでを通して行えば、その中ではSYSID不一致は起こらないはず、というわけです。
何かよい方法をご存知の方がいれば、是非、次回以降の関西FPGA・DE0勉強会で発表をw
では、どうするのがよいのか?
私の今の考えでは、GitHub等で公開する場合、複数のユーザが参照しうるが、ユーザ間で共同作業しない、という前提で、.sopcファイルのみをバージョン管理対象とするのがベター、と考えています。
cloneしたワーキングコピーそれぞれで、SOPC構成のgenerate～ファームウェアビルドまでを通して行えば、その中ではSYSID不一致は起こらないはず、というわけです。
何かよい方法をご存知の方がいれば、是非、次回以降の関西FPGA・DE0勉強会で発表をw
