[論文レビュー] Versatile firmware for the Common Readout Unit (CRU) of the ALICE experiment at the LHC

O. Bourrion, J. Bouvier+5 more|arXiv (Cornell University)|Oct 19, 2019

Advanced Data Storage Technologies参考文献 5被引用数 2

ひとこと要約

本論文は、CERNのLHCにおけるALICE実験の共通読み出しユニット（CRU）向けに、包括的で再利用可能なファームウェareフレームワークを提示する。このフレームワークにより、10台のアップグレード済み検出器における高スルーレートデータ取得が可能となり、連続的およびトリガー発生モードの両方をサポート。GBTおよびPONプロトコルを介したクロック、トリガー、スローカントロール信号の統合に加え、PCIe Gen3ベースのFPGA設計による動的リソース割り当てと設定可能なデータパスにより、データスルーレートを3.5 TB/sから635 GB/sに低減した。

ABSTRACT

As from the run 3 of CERN LHC scheduled in 2022, the upgraded ALICE experiment will use a Common Readout Unit (CRU) at the heart of the data acquisition system. The CRU, based on the PCIe40 hardware designed for LHCb, is a common interface between 3 main sub-systems: the front-end, the computing system, and the trigger and timing system. The 475 CRUs will interface 10 different sub-detectors and reduce the total data throughput from 3.5 TB/s to 635 GB/s. The ALICE common firmware framework supports data taking in continuous and triggered mode and forwards clock, trigger and slow control to the front-end electronics. In this paper, the architecture and the data-flow performance are presented.

研究の動機と目的

• LHCラン3におけるALICEのアップグレード検出器システムで、10,000の読み出しリンクから生じる3.5 TB/sのデータスルーレートを管理する課題に対処する。
• 共通のハードウェアプラットフォームを用いて、10台のアップグレード済みサブ検出器の多様な検出器要件を満たす統一されたファームウェアフレームワークを開発する。
• さまざまな物理学的目的および検出器構成に対応できるように、連続的（トリガーなし）およびトリガー発生データ取得モードの両方を可能にする。
• フロントエンドエレクトロニクス、コンピューティングシステム、およびトリガー・タイミングシステムを横断的に、クロック、トリガー、スローカントロール信号を効率的に統合する。
• バージョン管理、自動タグ付け、およびユーザー論理拡張性を備えたモジュラー設計により、ファームウェアの保守性と再現性を確保する。

提案手法

• LHCbのPCIe40設計を基にしたPCIe Gen3 x8 FPGAベースのCRUハードウェアプラットフォーム（24本のGBT光リンクおよび1本のTTS PONリンクを接続）を採用する。
• ボードサポートパッケージ（BSP）、GBTラッパー、TTSインターフェース、および設定可能なデータパスラッパーを用いたモジュラーなファームウェアスタックを実装し、柔軟なデータルーティングを実現する。
• ファームウェア検証および読み出しソフトウェアのテストのため、実際の検出器データをシミュレートするための検出器データジェネレータ（DDG）およびパターンプレーヤーを活用する。
• O2コンピューティングファームへの高帯域幅データ転送にはPCIe DMAを、制御メッセージにはBARインターフェースを用いる。
• I2Cベースの構成および監視機能をクロック、温度、電源、LEDに適用し、シミュレーションおよびデバッグ用にカスタムVHDLアドレスタブルを実装する。
• Gitベースのバージョン管理を採用し、自動タグ付け（gitハッシュおよびコンパイル日付を含む）を実施することで、トレーサビリティと再現性を確保する。

実験結果

リサーチクエスチョン

• RQ1 10種類の異なるALICEサブ検出器（帯域幅およびタイミング要件が異なる）において、1つのファームウェアフレームワークが、どのように多様なデータ取得要件を効率的に満たせるか？
• RQ2 統一されたファームウェア設計内で、連続的およびトリガー発生読み出しモードの両方を実現するために必要なアーキテクチャ的特徴および設定可能性は何か？
• RQ3 複雑な検出器システムにおいて、適応性を維持しつつ、リソース使用量を最小限に抑えるにはどうすればよいか？
• RQ4 共有ファームウェアリポジトリ内での検出器固有のユーザー論理の信頼性ある構成、検証、デプロイを保証するメカニズムは何か？
• RQ5 大規模な検出器システムにおいて、開発時間を短縮しエラーの早期解消を促進するために、ファームウェアのシミュレーションおよび統合をどのように簡素化できるか？

主な発見

• 共通のファームウェアフレームワークにより、10台のアップグレード済み検出器に跨る475台のCRUを集約することで、合計データスルーレートを3.5 TB/sから635 GB/sに低減した。
• ファームウェアは123kのアダプティブロジックモジュール（FPGA全体の29％）と1,084個のRAMブロック（全容量の40％）を消費しており、GBTラッパーが全ALM使用量の44％を占める最大のコンponentである。
• GBTモードとワイドモードの間での動的切り替えにより、TPCのような高リソース要件を持つ検出器で最大30kのALM節約が可能となり、効率的なリソース割り当てが実現された。
• VHDLベースのアドレスタブルを備えたシミュレーション対応の構成モデルの活用により、実世界の構成シーケンスおよびレアエラー事例の正確な再現が可能になった。
• ファームウェアのデプロイは完全にバージョン管理されており、自動タグ付けによりgitハッシュとコンパイル日付がステータスレジスタに埋め込まれ、完全な再現性が確保された。
• 565台のCRUが製造・設置され、検証作業が進行中であり、2021年末までに完全なコミissioningが予想される。