SoC開発において、CPU、DSP、メモリコントローラ（MC）、オンチップバス（OCB）、高速シリアルI/Fなど、システムの心臓部となる主要な機能部品をすべて自ら設計してきたからかもしれませんが、MCとOCB(NoC)こそがSoCプラットフォーム（以後SoCプラットフォーム）における「最重要部品」であり、しかもこの部品に最後まで苦しんできたので、お気楽の道を切り開く鍵もここにしかないと考えてます。
実は、このSoCプラットフォームは、中身の詳細を知らない人からすると想像もつかないほど、設計の進め方一つで恐ろしいほどのPPA（電力・性能・面積）の浪費を生み出してしまう、実に対処の難しい部品ということができるのです。
本稿では、実務の最前線で泥をすすりながら戦ってきたからこそ語れる、SoCプラットフォーム設計の本質と不条理な現実に触れてみたいと思います。
誰も本当の姿を知らない、SoCプラットフォームのブラックボックス
SoCプラットフォームは、システム全体の性能を決定づける超重要部品です。しかし、驚くべきことに、その内部動作や性能チューニングの本質を本当に理解している設計者は、どこにも存在しない、というのが業界のリアルな実態です。
「IPベンダーの担当者ならすべてを把握しているのでは？」と思われるかもしれませんが、彼らのスキルにも限界があります。これは決して、彼らを悪く言いたいわけではありません（プロジェクトでは本当に大変お世話になりましたし、深く深く感謝しています）。そうではなく、SoCプラットフォームが要求する調停や流量制御が、「そもそも人間が完璧に制御するには難しすぎる」という領域に達しているからなのです。
多くの場合、設計現場が直面する性能不足へのチューニングは、以下のような力技に頼らざるを得ないのが現状です。
メモリ追加の「お化け」による解決：
帯域が足りない、データが滞留するといった問題が起きるたびに、根本的な経路整理から逃げ、ただひたすらにバッファ（メモリ）を追加してごまかします。往々にして足りてる場合は減らさず見過ごし易い仕組みになっているため、この「メモリ追加お化け」が跋扈した結果、追加すればするほどリーク電力やシリコン面積といったPPAの無駄が、激増していくことになります。
物理設計（レイアウト）への凄まじいしわ寄せ：
OCBやMCのレイアウトインパクトは絶大です。物理的な配線がチップ全体に縦横無尽に広がるため、設計終盤の最終調整におけるタイミング収束のしわ寄せは、往々にしてこのプラットフォーム領域に集中します。レイアウトを無理やり収束させるために、消費電力が極めて高い「高リークセル」を嵐のように敷き詰めることになっても、「動かすためには、もうこれしかない！」と涙をのんで強行突破するのが、現場のお約束パターンなのです。
シナリオ検証という「砂上の楼閣」と、手戻りの恐怖
プラットフォームの性能検証（帯域が確保できているか、データの滞留・枯渇がないか）は、特定のユースケースを想定した「シナリオベース」で行われます。しかし、これは所詮、人間が頭の中で考えただけの限られたシナリオに過ぎません。
実際のSoCの動作において、何億、何百億通りと存在する複雑なデータアクセスの組み合わせ（シナリオ）をすべて事前にシミュレーションし、検査することなど、原理的に不可能です。すなわち、 「プラットフォーム全体の理想的な調整方法など、この世に原理的に存在しない」 のが冷酷な真実なのです。
さらに問題を厄介にしているのが、設計の終盤（フロアプランも配線もほぼ固まった時期）にならないと、実際に問題を引き起こすような「致命的なシナリオ」を絞り込んで作成することが容易ではない、という開発プロセスのジレンマです。
その結果、フロアプランのタイミング調整のゴールが見え始めた設計終盤において、突然「致命的な帯域問題（特定の条件下でデータが詰まり、バッファが破綻するバグ）」が発覚するという思い出したくもない大惨事すらが起こるのです。
このような不条理が蔓延する業界において、世の中のほとんどの設計者が何をやっているかといえば、決してギリギリの攻めた設計など到底怖くてできません。「これだけ過剰にマージンを積んで、PPAを犠牲にしておけば（おっと犠牲ではなく、気がつかないようにさえすれば）、たぶん大丈夫なはず……」という、極めて非効率で安全側に倒しすぎた、言い換えれば「祈るような設計」でお茶を濁しているのが現実なのです。
根本的な仕組みに潜む「諸悪の根源」と、後付けプロトコルの限界
なぜ、これほどまでにSoCプラットフォームの設計は泥沼化してしまうのでしょうか。元を正せば、そもそも私たちが使っているバスプロトコル仕様の「根本的な仕組み」そのものにも、諸悪の根源があります。
AMBAなどの標準バスプロトコルは、もともとこれほど複雑なマルチコアや大量のIPが接続されることを想定して作られていません。そのため、帯域制御や優先度制御（QoS）といった仕組みは、時代の進化とともに「後付け」で仕様にパッチを当てるように追加されてきた歴史があります。
しかし、このような後付けの帯域制御プロトコルが、万全に機能するはずもありません。
なぜなら、バスに接続される各マスター（プロセッサやハードマクロ）のアクセス特性は、必ずしも単位時間あたり一定の帯域を消費するような大人しいものばかりではないからです。
実機が一発アウトになる緊急マスターの存在：
例えば、液晶ディスプレイなどの画面表示を司るマスターや、リアルタイムの音声・映像出力を行うマスター、極めて高速な外部通信エンジンなどがこれに該当します。これらは、単位時間あたりのデータ転送量自体はそれほど多くなくても、内部のローカルバッファが空になりかけた「緊急時」に一瞬でもデータが枯渇すると、画面にノイズが走ったり、システム全体が即座にフリーズする『一発アウト』の特性を持っています。プロトコル上に後から付け足したような曖昧な優先度制御だけでは、このようなリアルタイムマスターの瞬間的な悲鳴を救い切ることは、構造上極めて難しいパズルを解かなければならないのです。
この問題をさらに複雑にしているのが、OCB（NoC）を開発しているベンダーと、MC（メモリコントローラ）を開発しているベンダーが、その歴史的背景において「同一ベンダーではなかった」という点です。
驚くべきことに、巨大なバスIPを提供しているOCBベンダーは、不思議なほどメモリコントローラ（MC）の自社設計を行っていません。その結果、OCBの上でどれほど必死に流量制御や帯域制御を頑張ったところで、OCBとMCの「境界（インターフェース部）」にデータが差し掛かった途端に、制御がバスプロトコルの規定により、本来やりたい制御を実現できないという問題を抱え込むことになっていたのです。
経路に存在するバッファは、大雑把に言えば先に入ったデータを先に出すだけの「FIFO（First-In, First-Out）構成」で設計されています。そのため、MCの手前でどれほど「緊急の調停（優先アクセス）」をしようとしても、すでにFIFOの奥深くに並んでしまったデータを途中の経路から魔法のように引き抜いて先に出すことなど、考えれば分かる通り、物理的な限界があるのです。
歴史の変遷と、ベストソリューション不在の複雑怪奇なIP選定
20年ほど前であれば、D社がメモリコントローラ（MC）市場を席巻していた時期がありました。しかしそれは、メモリコントローラに繋がるマスターデバイスの数が、まだ手足の指で数えるほど少なかった時代の牧歌的なお話にすぎません。
今の最先端SoCのように、100以上のマスターデバイスがひしめき合う超大規模な環境ともなると、SoCプラットフォーム（PF）設計の難易度は天文学的に跳ね上がります。MCの入口に到達する前に、オンチップバス（OCB）の内部でいかに効率よく流量制御を行うかが生死を分けるのです。
しかも、私たちが対峙しなければならないメモリ周りの構造は、年々複雑怪奇さを増しています。
まず、外付けメモリはもはや単一のDRAMだけではありません。必要とされる圧倒的な帯域（バンド幅）の要求に応じて、DDR系はもちろん、近年最もホットな領域である「HBM（High Bandwidth Memory）」系など、多様な選択肢から最適解を選び取る必要があります。
さらに、チップの内部に大規模なSRAMをギチギチに抱え込み、それを外付けメモリの「キャッシュ」として機能させるテクニックも日常茶飯事です。これにより、ただでさえ通り道の狭い内部データ経路は、さらにスパゲッティのように複雑化していきます。
そして現在、最もホットな技術トレンドはメモリ構造そのものの「3次元化（3D積層）」です。これにより、OCB構造自体にも、3次元空間に存在する立体的なメモリ群に対して、最も低レイテンシかつ高効率にアクセス・調停する高度なルーティング技術が求められるようになりました。
これだけでも目眩がしそうですが、実務においては「メモリ調達の代替品（セカンドソース）確保」や「きめ細かな省電力化の制御」、極めつけに「IPライセンス費用やロイヤリティの問題」といった大人の都合も容赦なく降ってきます。結果として、複数の異なるメモリプロトコルを同時にサポートし、動的に切り替えられるマルチプロトコル対応の設計をコストも考慮して選択しなければならないのです。
こうした最新の複雑なメモリシステムに対応できる「統一的なベストソリューション」は、残念ながらこの世に存在しません。これが、大規模ASIC設計のすべての苦労が最終的にSoCプラットフォームへと集中してしまう、紛れもない原因なのです。
まとめ：PFの泥沼を「お気楽」に変えるために
SoCや大規模ASIC設計におけるあらゆる苦労と矛盾は、開発プロセスの最後に、この「SoCプラットフォーム」という名の泥沼に集約されます。
設計者にとっての理想的なあるべき姿は、このような最後の最後での手戻りや、PPAをドブに捨てるような過剰設計に悩まされることのない「完璧に整合性の取れたプラットフォーム」を、開発の最初から手に入れることです。
しかし、これまでに述べてきた通り、自社の要件に完璧にフィットする最適なプラットフォームを見極め、選定し、正しくチューニングして手に入れること自体が、一朝一夕には決して真似のできない「超高度なノウハウの塊」に他なりません。
もし、貴社の開発現場において、
- ベンダー選定の時点で、どのバスとメモリコントローラの組み合わせが最適なのか見当がつかない
- 設計終盤のシミュレーションで帯域不足が発覚し、胃が痛い思いをしている
- 無駄なメモリや高リークセルだらけの、贅肉だらけのプラットフォーム設計から脱却したい
といった深刻なお悩みがございましたら、ぜひ、MyokeResearchの知見を、貴社の 「強力なアドバイザーとして使い倒して」 いただきたいのです。最適なプラットフォーム選定から、破綻のない流量制御アーキテクチャの定義、そしてベンダーとのシビアな交渉まで、貴社の強力な右腕として「お気楽で、バグのない開発フロー」の構築を全力でサポートいたします。ぜひ、最初の一歩として、以下のリンク先からお気軽にお問い合わせやリクエストをお寄せください。不条理な泥沼を脱出し、スマートで楽しい「お気楽ASIC開発」を一緒に始めましょう！
参考文献・リンク
