OCAシステムアーキテクチャの仕様書を日本語に翻訳して、Sphinxでドキュメント化している。 OCAは、異なるベンダーのチップレットがオープンなエコシステムで連携することを可能にするシステムアーキテクチャとのこと。
4.4節 システム管理の本質
4.4節のシステム管理をChaptGPTの力を借りて、読み進めて理解した、最も重要なポイントは1つ：
「システム管理は"最後まで生き残る経路"として設計せよ」
System Management が扱うのは、性能や帯域とは無関係な、生存性のための通信である。 具体的には、Boot / Reset 制御、電源・クロック管理、エラー通知（RAS）、セキュリティ状態遷移、設定・列挙（Enumeration）など。「これが止まると、もう何も直せない」通信である。
4.4 の要点を設計原則に落とすと、次の5点である。
- データ系と分離せよ: 物理的 or 論理的に独立し、クレジット／VC を共有しない
- 非循環トポロジにせよ: スター／ツリー型、自己ループ禁止、解析不要な進行保証（ここで
OPT-FABRIC-1と整合） - 最低限の機能だけを載せよ: 小さいバッファ、単純プロトコル、順序保証は最小限。「高機能」はむしろ害である
- 依存関係を作るな: 管理経路がデータ経路、アドレス変換、キャッシュ整合に依存しない
- 常に到達可能であれ: ブート途中でも、一部チップ死んでいても、エラー状態でも
System Management は「破綻時設計」と考えることができる。
誤設計としては管理通信を AXI/CHI に統合、データファブリックと VC 共有、高性能 NoC に「ついでに載せる」、ループ構造で「多重化して安心」などがあるが、全部、異常時に死ぬ。
4.5節 システム時間管理の要点
4.5節は 「チップレット間で"時間"をどう扱うか」 を定義しているが、対象は単なるクロック配信や時刻同期そのものではない。 扱っているのは、チップレットごとに時間基準が異なる可能性、同期が未完了・一時的に失われる・そもそも不要／不能である状態、それでもシステムとして整合性を保つ必要性である。
中核となる考え方は、時間は「共有前提の資源」ではなく、「状態として管理されるべきもの」であること。 単一SoCのように、同一PLL、同一クロックツリー、同時リセットを前提にした「暗黙の時間共有」はチップレットでは成立しない、という前提に立っている。
4.5 が要求していることは以下の3点である。
- 時間基準の明示性: 各チップレットが、どの時間基準（clock / counter）を使っているか、グローバル時間とどういう関係にあるかを明示的に扱えること
- 同期状態の可視化: 同期されているか、どの程度の誤差があるか、同期が失われているかを状態として認識・通知できること（「常に同期していなければならない」とは言っていない）
- 非同期・不完全同期を前提とする設計: 一部チップレットがスリープ、電源断、リセット中であっても、時間管理そのものが破綻しないことを重視している
4.5 は次を要求していない： - 高精度なグローバルクロック配布 - 常時ナノ秒精度の同期 - PTP や TSN のような特定方式の採用
4.5 は 方式非依存である。
そのため、「時間が正しいかどうか」をアーキテクチャとして管理せよという位置づけになっている。
