プログラミング
XLS: 高速化されたハードウェア合成
XLS: Accelerated HW Synthesis (google.github.io)
要約
XLS(Accelerated HW Synthesis)は、Googleが開発した高位合成(HLS)ツールチェーンです。ソフトウェアエンジニアがハードウェアIPを迅速に開発できるよう支援し、ハードウェア記述言語(Verilog/SystemVerilog)を生成します。このプロジェクトは実験段階にあり、Apache 2ライセンスで提供されています。
全文翻訳
XLS: 高速化されたハードウェア合成
XLSとは何か?
XLSは、柔軟な高レベル記述から合成可能なデザイン(VerilogおよびSystemVerilog)を生成する高位合成ツールチェーンを実装しています。Apache 2ライセンスです。
XLS(Accelerated HW Synthesis)は、ムーアの法則の終焉(EoML)時代のソフトウェア開発キット(SDK)となることを目指しています。この「専門化の時代」において、ソフトウェアエンジニアとハードウェアエンジニアは、ドメイン境界を越えてより多くの協調設計を行う必要があります。共有アーティファクトで協力し、互いのコストモデルを理解し、ツール/方法論を共有する必要があります。XLSは、自動化、ソフトウェアエンジニア、およびマシンサイクルを活用して、この全体的なプロセスを加速しようとします。
XLSは、ソフトウェアスタイルの方法論を通じて、効率的なホストソフトウェアとしても実行されるハードウェアIPの迅速な開発を可能にします。XLSデザインは、ホストソフトウェアまたはシミュレータで使用するためにネイティブ速度で実行されますが、そのデザインはハードウェアブロック出力も生成できます。XLSツールの正確性は、それらが機能的に同一であることを保証し(そして形式的に検証するためのツールを提供します)。XLSは、純粋なワイヤーI/Oインターフェースを持つ(オプションでパイプライン化された)関数と、並列プロセス(またはproc)の両方をサポートします。Procはステートフルであり、時間の経過に伴う帰納を可能にし、より一般的な通信インターフェースを含みます。
プロジェクトの現状
XLSは実験的なものであり、急速に開発が進められており、Googleの公式サポート製品ではありません。バグや未熟な部分が予想されます。試してみて、チュートリアルをいくつか実行し、バグを報告して協力してください。私たちは初期段階にあり、これにはいくつかの実際的な影響があります。問題(issues)とプルリクエスト(PRs)を歓迎します。まず問題提起から始めてください。変更をアップストリームしたい場合は、私たちと対話してください。問題提起なしにPRを送信すると、成功への道のりが長くなる可能性があります。PRが準備完了であり、2営業日以内に応答がないと思われる場合は、次のステップと思われるものを問題提起で ping してください。現在の進化段階では、後方互換性を考慮せずにDSLXを定期的に改善しています。XLSでハードウェアのコーパスを構築している場合は、コンパイラの新しいバージョンを取り込むプロセスについて慎重に検討してください。
Colab Notebooks
セットアップ不要で環境に依存しない方法でXLSを試すには、Colab Notebookをご覧ください。
bit.ly/learn-xls: DSLX(Rustにインスパイアされたドメイン固有言語)での「Y分でXLSを学ぶ」スタイルのウォークスルー。
bit.ly/xls-playground: 以下のものをインタラクティブに実行できるXLS評価環境。
- XLSテスト
- XLS→IR変換
- IR→Verilogコード生成
- YosysによるVerilog合成(オープンPDKのASAP7およびSKY130を使用)
- OpenROADによる配置配線(P&R)
- 電力/パフォーマンス/エリア(PPA)メトリック収集
最新リリースをインストール
以下のコマンドは、x64 Linuxマシン用の最新のGitHubリポジトリリリースバイナリをダウンロードします。
# 最新リリースtarballのURLを決定します。
LATEST_XLS_RELEASE_TARBALL_URL=$(curl -s -L \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/google/xls/releases | \
grep -m 1 -o 'https://.*/releases/download/.*\.tar\.gz')
# tarballをダウンロードして展開し、含まれる各ツールのバージョン番号を確認します。
curl -O -L ${LATEST_XLS_RELEASE_TARBALL_URL}
tar -xzvvf xls-*.tar.gz
cd xls-*/
./interpreter_main --version
./ir_converter_main --version
./opt_main --version
./codegen_main --version
./proto_to_dslx_main --version
ソースからビルド
バイナリリリース(上記の説明の通りx64 Linux用)、および利用可能なColab Notebookに加えて、XLSはBazelビルドシステムを使用してソースからビルドする必要があります。以下の手順は、Ubuntu 22.04(Jammy Jellyfish)Linuxディストリビューション用です。平均的な8コアVMで:
C++フロントエンドなしの完全な初期ビルド(例:「DSLXのみ」)は約2時間かかる場合があります。C++フロントエンドを含めると最大6時間かかる場合があります。以下の2つの対応するコマンドラインを参照してください。まずBazelがインストールされていると仮定します。
~$ git clone https://github.com/google/xls.git
~$ cd xls
~/xls$ # Bazelのインストール手順に従ってBazel 7をインストールします。
~/xls$ # https://bazel.build/install/ubuntu
~/xls$ # ここで、`/usr/bin/env python` が実際にはpython3であることをUbuntuに通知します。
~/xls$ # 過去のUbuntuではデフォルトでそうではありませんでした。
~/xls$ # これは重要です。この手順なしでは、不可解なエラーメッセージが発生する可能性があります。
~/xls$ sudo apt install python3-dev libtinfo6 python-is-python3
~/xls$ # 最適化ビルドモードでビルド/テストします。
~/xls$ # C++フロントエンドを使用しない場合(厳密には必要ありません。
~/xls$ # つまり、DSLXフロントエンドのみの場合)は、このコマンドラインを使用してください。
~/xls$ bazel test -c opt -- //xls/... -//xls/contrib/xlscc/...
~/xls$ # すべてをビルドするには、C++フロントエンドを含めてください。
~/xls$ bazel test -c opt -- //xls/...
Dockerビルド参照
ビルド/テスト環境の設定は、Dockerfilesを介しても提供されています。上記の(限定された)依存関係のセットを環境に設定するのが難しい場合は、これを使用してください。
~$ git clone https://github.com/google/xls.git
~$ cd xls
~/xls$ # XLSテストをビルドして実行します。
~/xls$ docker build . -f Dockerfile-ubuntu-22.04
~/xls$ # XLSビルド環境を設定し、手動テスト/ビルドを可能にします。
~/xls$ docker build . -f Dockerfile-ubuntu-22.04 \
-t xls-build-docker \
--build-arg SKIP_TESTS=1 \
...
~/xls$ docker run -it --rm xls-build-docker /bin/bash \
...
xls-developer@de12154edf52:~/xls$ bazel build --verbose_failures -c opt //xls/jit:jit_channel_queue_test \
...
追加のビルドキャッシュの追加
多くのプログラマーはccacheのようなプログラムを使用してビルドのキャッシュを改善することに慣れていますが、Bazel自体は非常に高品質なキャッシュレイヤーを備えています。特に、増分ビルドはより安全です。しかし、Bazelがローカルでキャッシュされた結果を使用してファイルを再コンパイルする決定をする場合、またはbazel cleanの後でも特定の途中結果を再利用するのが安全な場合があります。これを改善するために、Bazelに永続的にディスク上の別の場所にファイルを保存する共有「ディスクキャッシュ」を使用するように指示できます。どこかにディレクトリを作成し(例: ~/.bazel_disk_cache/)、以下を実行します。
echo "build --disk_cache=$(realpath ~/.bazel_disk_cache)" >> ~/.bazelrc
echo "test --disk_cache=$(realpath ~/.bazel_disk_cache)" >> ~/.bazelrc
警告
Bazelは、このディレクトリのガベージコレクションを自動化しないため、時間とともに無制限に成長します。定期的に、手動または自動スクリプトでクリーンアップする必要があります。あるいは、ガベージコレクションを処理するリモートキャッシュを追加することもできます。これは、個人サーバーまたはローカルマシンでホストできます。私たちは個人的にlocalhostインスタンスのbazel-remoteで良好な結果を得ています。
Clangd補完の取得
clangd補完および関連機能を取得するには2つの方法があります。clangdおよび類似ツールと互換性のあるcompile_flags.txtファイルは、xls/dev_tools/make-compilation-db.shを実行して作成できます。このアプローチは高速ですが、個々のターゲットがビルドされる方法の違いを考慮していません。代替として、hedronvision/bazel-compile-commands-extractorを使用して、clangdが消費できるcompile_commands.jsonファイルを生成できます。このアプローチはセットアップに時間がかかりますが、コンパイラフラグは各ターゲットに合わせて調整されています。compile_commands.jsonファイルは、以下を実行してビルドできます。
bazel build -c opt //xls/... -k
bazel run //:refresh_compile_commands
詳細については、トップレベルのBUILDファイル内のコメントを参照してください。
スタック図とプロジェクトレイアウト
新しいコードベースのナビゲーションは daunting である可能性があります。以下の説明は、重要なディレクトリとそれらの意図された組織/目的のハイレベルビューを提供し、このXLSスタック図のコンポーネントに対応します。
dependency_support: XLSの外部依存関係のBazelターゲットをロード、ビルド、公開するための設定ファイル。
docs_src: Markdownファイルソース。mkdocs経由でドキュメントにレンダリングされます。
xls: Bazelプロジェクトの一般的なスタイルで、リポジトリ内のプロジェクト名のサブディレクトリ。
- build: