Vengineerの妄想

公開情報の断片から、AI半導体の実装と次の一手を読む。

Cerebras Systems の WSE-3 Turbo、WSE-3とWaferの見た目が違う？

はじめに

Cerebras SystemsのYoutubeにアップされた下記の動画。CS-4 と WSE-3 Turbo に関する色々なものが映っています。

www.youtube.com

この動画を見て気が付いたことを記録に残します。以下、この動画から画像を説明のために引用します。

I/O Tile っぽいものがあるんだ。

今更ながら、WSE には、Compute Tile (Compute Die) だけでなく、I/O Tile (I/O Die) の領域があるようです。

これ

Compute Tile の長手方向の辺に、Compute Tile と同じ数の I/O Tile っぽいものがあります。

2023年1月24日のブログに、WSE-3 の Wafer の写真を載せました。

vengineer.hatenablog.com

その写真の I/O Tile の部分の拡大を下記のXに投稿しました。

この写真から、WSE-3 の I/O Tile には、

  • 端っこの I/O Tile : 6 + 10 の Pad
  • 真中の5つの I/I Tile : 10 + 10 の Pad

が見えます。

I/O Tile の部分が違う

ここで、WSE-3 と WSE-3 Turbo では、I/O Tile の部分がちょっと違うことがわかりました。

WSE-3 の I/O Tile の外側には穴がありませんが、WSE-3 T の I/O Tile の外側に穴があります。

この I/O Tile の部分に追加された穴。これは、上から押さえるコンタクト機構が追加・変更されたのではないか、と思います。

I/O Tile は、下記の部分に接続して、外側に引き出されている。

引き出された部分に、I/O Module が接続する感じになりますね。I/O Module 内で、ここと接続するASICから4本の 400GbE(たぶん)出ています(I/O Moduleの両側の2本ずつ)

ちなみに、CS-1/2/3 では、下記のように、I/O Module は垂直方向に接続されていました。

Wafer と I/O Module とのコネクタはこんな感じになっています。

ちなみに、この動画は、2024.3.23 にアップされています。

I/O Module の位置関係

おわりに

CS-4の公式ページ => これ

に、WSE-3 Turbo として、3枚のWafer が載っている写真があります。下記に説明のために引用します。

これには、I/O Tile の外側に穴が無いので、実は WSE-3 Turbo ではなく、WSE-3 ではないか？と思っています。

OpenAI の Jalapeñoの評価ボードを見ていたら、Broadcomのロゴが見えた

はじめに

OpenAIのJalapeñoについて書かれたブログ「Jalapeñoの初期結果は、AI推論において業界トップクラスの速度と効率を示しています」を読み返していたら、ちょっと気になるものを見つけたので記録に残しておきます。

それは、評価ボードの写真です。

上記のブログに掲載されている評価ボードの写真を見ると、ボードの下の方にBroadcomのロゴの一部が見えます。

まあ、Jalapeñoのチップ開発にはBroadcomが関係していることが知られているので、ボード開発にもBroadcomが関係しているとしても、「まあ、そうだよね」という感じではあります。

下記のブログにも書きましたが、Jalapeñoの開発ではBroadcomだけでなく、Celesticaなども関係しているのではないかと妄想しています。

vengineer.hatenablog.com

OpenAIが全部やったわけではない？

ここからは、いつものVengineerの妄想です。

Jalapeñoの構成を考えると、OpenAIが担当したのは、やはりCompute Dieの部分が中心なのではないでしょうか。

一方で、HBM ControllerやI/O Die、PCIe、Ethernet、SerDesなど、チップの周辺部分については、Broadcomが持っている既存の技術やIPをかなり活用しているのではないかと思っています。

もちろん、実際の担当範囲は公開されていないので、これはあくまで妄想です。

ただ、もしOpenAIがこれらをすべてゼロから開発していたとすると、かなり大変です。

Compute Architectureを決めて、RTLを書いて、検証して、HBM Controllerを作って、PCIeを作って、Ethernetを作って、I/O Dieを作って、パッケージを作って、評価ボードまで作る。

これを全部やっていたら、9か月という開発期間はかなり厳しいんじゃないでしょうか。

だからこそ、既に実績のあるBroadcomの技術を利用し、OpenAIは「自分たちが本当に差別化したいCompute部分」に集中したのではないか、と考えると、かなり納得できます。

そして、評価ボードについても、BroadcomやCelesticaが関わっていたとすれば、その方が都合がいいでしょう。

チップだけではなく、HBM、PCIe、Ethernet、電源、クロック、基板、冷却などを含めたシステムとして動かす必要がありますからね。

800GbEをどうする？

ここで気になるのが、JalapeñoのI/Oです。

下記のSemiAnalysisの記事では、PCIe Gen5 x8、そして800GbE x 32 lanesという構成が紹介されています。

newsletter.semianalysis.com

PCIe Gen5 x8については、Broadcom側としても、これまでに十分な経験がある領域でしょう。

一方で、800GbE x 32 lanesとなると話が変わります。

800GbEを実際のシステムで動かすためには、単にEthernetのRTLが動けばいいという話ではありません。

SerDes、PCS、MAC、PHY、基板、コネクタ、信号品質、電源、冷却、そしてネットワーク機器との接続まで、システム全体で確認する必要があります。

しかも、Jalapeñoは単体で動けばいいチップではなく、大規模なAIシステムの中で使うことが前提です。

となると、I/O部分についてもかなり早い段階から動作確認を進めておきたいところです。

ESが来てから全部確認したのではない？

ここで、Jalapeñoの開発期間がちょっと気になります。

OpenAIによれば、Initial RTLからEngineering Sample（ES）までが約9か月。そして2026年5月にESを入手し、その同じ月にはCodexがJalapeño上で動作した、という話があります。

これ、よく考えると結構すごいんですよね。

5月にESが届いてから、

「さあ、PCIeを確認します」

「次にEthernetを確認します」

「HBMを確認します」

「I/Oを確認します」

「ドライバを作ります」

「システムを組みます」

「ではCodexを動かします」

……なんてやっていたら、かなり忙しいです（笑）。

なので、ここからは完全にVengineerの妄想ですが、Compute DieのESが届く前に、Broadcom側などでI/OやHBM周辺について、かなりの部分まで事前に動作確認が進んでいたのではないでしょうか。

例えば、I/O Die、PCIe、Ethernet、HBM周辺の検証やBring-upを、FPGAや既存のBroadcom製品、あるいは別の評価環境などを使って先行して進めておく。

そして、いよいよJalapeñoのCompute Dieが届いたら、それまでに確認していた周辺環境と接続して、Compute部分をBring-upする。

そう考えると、「ESを入手した月にCodexが動いた」という話も、少し現実味が出てきます。

9か月で全部作ったのではなく、9か月で差別化部分を作った？

そう考えると、Jalapeñoの9か月という開発期間についても、少し見方が変わってきます。

「AIチップを9か月で全部作った」

というより、

「既に存在する半導体技術、IP、I/O、HBM、パッケージ、基板などを最大限に活用して、OpenAIが差別化したいCompute Dieを9か月で作った」

と考えた方がいいのかもしれません。

もちろん、本当のところはOpenAI、Broadcom、Celesticaなどの関係者にしか分かりません。

でも、評価ボードの隅に見えるBroadcomのロゴを眺めながら、

「もしかして、Compute Dieが完成するずっと前から、周辺部分は動いていたんじゃないの？」

と妄想すると、Jalapeñoの開発スピードの理由が少し見えてくるような気がします。

AIチップ開発というと、どうしても「どんなCompute Architectureなのか」に目が行きます。

でも実際の製品化では、Compute Dieだけでは何もできません。

HBM、I/O、PCIe、Ethernet、SerDes、パッケージ、基板、電源、冷却、ソフトウェア……。

これらを全部まとめて「動くシステム」にする必要があります。

そう考えると、Jalapeñoの9か月という数字は、OpenAIだけのスピードというより、OpenAIとBroadcomなどが、それぞれ得意なところを分担した結果として実現した9か月なのかもしれません。

おわりに

ということで、評価ボードの隅っこに見えるBroadcomのロゴから、いろいろ妄想してみました。

発表は、9か月間で codex が動いた！となっていましたが、色々な施策をして、動かしたって、感じですかね。

AI半導体設計、番外編 : 将棋の藤井聡太名人から学ぶ

はじめに

ここまで4回にわたって、

  1. OpenROADをAIに改造させる
  2. OpenROADの結果からAIにRTLを改造させる
  3. さらに上流のArchitectureをAIに探索させる
  4. AIにRTLを書かせるのではなく、AIにチップの設計空間を探索させる

とブログにアップしました。

ここで、ふと思いました。

これって、将棋と似ていないか？

「何故？将棋なのか？それは、おこちゃまに、小学生の時に将棋をやっていて、色々な大会に保護者として行ったからです。」

もちろん、半導体設計と将棋が同じだと言いたいわけではありません。でも、「巨大な探索空間の中から、評価しながら良い解を探していく」という構造を見ると、かなり似ています。

将棋では、ある局面に対して候補手があります。一つの手を選んで終わりではありません。その手を指したら相手がどう応じるのか、その次にどうするのか、と先の局面を大量に探索していきます。そして、それぞれの局面を評価して、「こちらの方が良さそうだ」と候補を絞っていく。

AI半導体設計も似ています。

現在のWorkloadや仕様が「局面」です。そこからArchitectureの候補を作る。「MACを何個にするか」「SRAMをどれだけ載せるか」「Memory hierarchyをどうするか」「NoCをどう構成するか」「Pipelineを何段にするか」など、いろいろな候補がある。

その候補をRTLにして、Synthesisして、OpenROADでPlacement、CTS、Routingまで進める。そこでArea、Timing、Power、Congestionなどを評価する。そして、その結果を見て「このArchitectureは良かった」「これは物理的に厳しい」と判断し、次の候補を作る。

つまり、

Architecture候補を生成 → 実装 → 評価 → 次の候補を生成 → 再評価

という探索ループです。

将棋で言えば、「候補手を考える → その先を読む → 局面を評価する → 別の候補を読む」というループに近い。

ここで藤井聡太名人の将棋を考えると、さらに面白くなります。

藤井名人の強さを単純に「正解の手を知っている」と考えると、本質を外してしまう気がします。もちろん棋力や経験、読みの深さなど、いろいろな要素がありますが、重要なのは「この局面なら何を指すべきか」を大量の候補の中から探索し、評価し、さらに相手の応手まで含めて判断する能力です。

これは、今回考えているAIによるArchitecture Explorationにも通じます。

AIに「正解のArchitecture」を教えるのではない。

むしろ、

「この条件で一番良いArchitectureを探せ」

とする。

そしてAIが候補を作り、EDAが現実を教える。

ここでOpenROADが重要になります。

将棋にはルールがあります。どの手が合法なのか、指した結果どんな局面になるのかが明確です。そして、その局面を評価することができます。

半導体設計では、OpenROADがある意味で「現実のルール」を教えてくれる。

Architecture上では「これは速そうだ」と思っても、実際にPlacementしてみたらCongestionが酷いかもしれない。SRAMを増やしたらHBMアクセスは減ったが、Areaが大きくなりすぎるかもしれない。演算器を増やしたらPerformanceは上がったが、Routingが成立しないかもしれない。

AIの頭の中だけで考えていると、こうした現実は分かりません。

だから、

AI → Architecture → RTL → OpenROAD → Physical結果 → AI

というループが重要になる。

そして、もう一つ将棋と似ていると思うところがあります。

失敗した候補も情報になることです。

将棋なら、「この手を指すと相手にこう返されて不利になる」という読みが得られる。半導体なら、「このMemory構成ではAreaが増えすぎる」「このPipelineではPowerが悪化する」「このNoCではRouting congestionが発生する」という情報が得られる。

つまり、良いArchitectureだけを集めるのではなく、なぜ悪かったのかという失敗も設計空間の情報になる。

これを大量に蓄積していけば、AIは「この条件なら、この方向は危ない」という設計空間の地図を作っていけるかもしれません。

ここまで来ると、AIによる半導体設計は「コード生成」というより「探索問題」と考えた方がしっくりきます。

実はこれは、HLSのDesign Space Explorationにもつながっています。HLSでは人間がPipelineやUnrollなどの設計空間を定義し、その中から良い組み合わせを探索してきました。

今回の妄想は、その探索範囲をさらに広げるものです。

人間が設計空間を全部決めるのではなく、AI自身が「こんなArchitectureもあり得るのではないか」と候補を作る。そしてOpenROADが物理的な現実を返す。

さらに、「RTLを変えるべきか」「Architectureを変えるべきか」「Floorplanを変えるべきか」という、どの階層を探索するかまでAIに判断させる。

そうなると、人間の役割も変わってくるかもしれません。

人間が一つ一つRTLを書いて最適化するのではなく、「このWorkloadに対して、Performanceを最大化したい。ただしAreaとPowerにはこの制約がある」と目的と制約を定義する。

そしてAIが設計空間を探索する。

もちろん、現時点で藤井名人のようなAIがチップを設計できるわけではありません。将棋と半導体設計では探索空間の性質も、評価方法も、制約も全く違います。

それでも、「正解を生成する」のではなく、候補を大量に作り、評価し、失敗から学び、さらに候補を作るという考え方は共通しています。

そう考えると、生成AI時代の半導体設計で本当に重要になるのは、単純なRTL生成能力ではないのかもしれません。

「どれだけ上手にコードを書けるか」ではなく、「どれだけ広い設計空間を探索し、その中から良い解を見つけられるか」。

そして、その探索の相棒としてOpenROADのようなオープンなEDAが存在する。

おわりに

なんだか、半導体設計者が将棋盤の前に座っているような未来が見えてきました。

もちろん、これはVengineerの妄想です。

でも、もしかすると半導体設計の未来は、「AIに設計してもらう」のではなく、

「AIと一緒に、まだ誰も見つけていない設計を探索する」

という方向に進むのかもしれません。

AI半導体設計、第4回 : AIにRTLを書かせるのではなく、AIにチップの設計空間を探索させる

はじめに

ここまで、OpenROADと生成AIについて3回にわたって考えてきました。

  • 最初は「OpenROADをAIに改造させる」。
  • 次に「OpenROADの結果を見てAIにRTLを改造させる」。
  • そして「RTLのさらに上にあるArchitectureをAIに探索させる」。

ここで一つ重要なことがあります。

Design Space Explorationそのものは、新しいものではありません。

HLSでは以前から、Pipeline、Loop unroll、Array partition、Resource sharingなどを変更し、生成されたRTLをSynthesisしてPPAを比較するというDSEが行われてきました。

では、今回考えているAIによるDSEは何が違うのか。

AIによる Design Space Exploration

一つは、AIが探索空間そのものを作れる可能性です。

従来のDSEでは、人間が「このパラメータを変えてみよう」と設計空間を定義します。AIなら、Workloadや制約、過去の設計結果を見ながら、「そもそも別のArchitectureを考えた方がいいのではないか」と探索対象そのものを広げられる。

もう一つは、Physical Designまで強くfeedbackできることです。

Architectureを決め、RTLを生成し、Synthesisするだけでは、本当のチップの姿は分かりません。Placement、CTS、Routingまで進めると、Congestion、Wirelength、Clock、配線によるTiming degradationなど、上流では見えなかった問題が出てきます。

OpenROADをここに入れる。

AIがArchitectureを考え、RTLを作り、OpenROADで実装し、その結果を見てまたArchitectureを変更する。

さらに、AI自身に「どの設計階層を変更するか」を判断させる。

Timingが悪いならRTLを変えるのか。Architectureを変えるのか。Floorplanを変えるのか。それともPlacementやRoutingを変えるのか。

これは単なるパラメータ探索ではありません。設計のどこを変更するべきか、という判断そのものを探索するという話です。

そうなると、AIに一発で正解のRTLを生成させる必要もなくなります。

100個のArchitectureを考えさせてもいい。そのうち99個がダメでもいい。重要なのは、その中から人間が思いつかなかった良い候補が出てくることです。

そして失敗した99個も無駄ではありません。

「このMemory構成ではAreaが増えすぎる」「このPipeline構成ではPowerが悪化する」「このNoC構成ではRouting congestionが厳しい」。

こうした失敗を蓄積すれば、AIは設計空間の地図を少しずつ作っていけるかもしれません。

もちろん、全部をOpenROADで評価していたら計算量が大きすぎます。だから代理モデルで大量の候補を絞り、有望なものだけOpenROADで高精度に評価する。

OpenROADは、AIにとって「RTLをGDSIIにするツール」であると同時に、Architectureを現実の物理世界で試すための実験装置になります。

そう考えると、HLSとの関係も見えてきます。HLSのDSEは、人間が定義した設計空間を効率よく探索する技術として非常に重要でした。

その次にAIがやろうとしているのは、その設計空間をAI自身が広げ、Architecture、RTL、Physical Designをまたいで探索することなのかもしれません。

半導体設計の自動化は、回路図からHDLへ、HDLからHLSへと、徐々に抽象度を上げてきました。そして生成AIの時代には、さらに一段上がるのかもしれません。

「AIにRTLを書かせる」のではなく、「AIにチップの設計空間を探索させる」。

これが、生成AIと半導体設計の次の接点になるのではないか。

おわりに

そして、ここまで考えていたら、ちょっと別の世界が頭に浮かびました。

これって……将棋と似ていないか？

次回は番外編。なぜか半導体設計の話が、将棋に繋がってしまった、という妄想を書いてみたいと思います。

AI半導体設計、第3回 : さらに上流のArchitectureをAIに探索させる

はじめに

ここまで来ると、話をもう一段上げたくなります。「RTLをどう書き換えるか」ではなく、そもそも、どんなArchitectureが良いのかをAIに探索させる。

例えばLLMのDecode処理を高速化するASICを考えてみます。このとき重要なのはRTLの記述方法だけではありません。演算器を何個置くのか、SRAMをどれだけ持つのか、Memory bandwidthをどれだけ確保するのか、Pipelineを何段にするのか、NoCをどう構成するのか。こうしたArchitectureの決定が、最終的なチップ性能を大きく左右します。

Architecture を見つける

そこでAIにArchitecture候補を考えさせる。そして、それぞれをRTLに落とし、SynthesisしてOpenROADでPhysical Designする。Area、Timing、Power、Congestionなどを測定し、その結果をAIに返す。AIは結果を見て、次のArchitectureを考える。

ここで、「それって高位合成でもやっていたよね？」という話になります。

その通りです。HLSでは以前からDesign Space Explorationが行われてきました。Pipeline、Loop unroll、Array partition、Resource sharing、並列度などを変更し、生成されたRTLをSynthesisしてPerformanceやArea、Powerを比較する。つまり、HLSにも設計空間を探索する仕組みがあります。

今回考えているAIによるArchitecture Explorationは、HLSを否定する話ではありません。むしろ、その先を考えています。

HLSでは、人間が「ここをunrollする」「この配列をpartitionする」といった探索対象を決めることが多い。つまり、人間が設計空間を定義し、その中をツールに探索させる。

AIにやらせたいのは、その設計空間そのものを広げることです。

例えばLLM Decode用ASICなら、Pipeline段数だけではなく、MAC数、SRAM容量、Memory hierarchy、HBMアクセス、Dataflow、NoC、Resource sharingなど、Architectureそのものを候補として考える。

そしてさらに重要なのがPhysical Designです。Architecture上は良さそうでも、PlacementしてみるとCongestionが発生する。配線長が増えてTimingが悪化する。Clock treeやRoutingによって想定外の問題が出る。

だからOpenROADを評価ループに入れる。

Architectureを変更する。RTLを生成する。Synthesisする。OpenROADでPlacement、CTS、Routingまで進める。そしてPhysical Designの結果をAIに返す。

するとAIは、「このArchitectureは理論上は速いが、物理的には成立しない」ということまで知ることができます。

つまり、

Architecture → RTL → Physical Design → PPA → 次のArchitecture

というfeedback loopです。

もちろん、1000個のArchitectureを全部OpenROADで評価するのは重すぎる。そこで代理モデルを使い、有望な候補だけを詳細評価する方法も考えられます。

さらに面白いのは、AI自身に「どこを変更するか」を判断させることです。Timingが悪いならRTLを変えるのか、Architectureを変えるのか、それともFloorplanやPlacementを変えるのか。

人間の設計者なら経験から判断しています。「これはEDAで頑張るよりArchitectureを変えた方がいい」。

この判断までAIにさせる。

おわりに

HLSがやってきたDesign Space Explorationを、AIによってもっと上流へ、もっと広い空間へ、そしてPhysical Designまで含めたclosed-loopへ拡張する。

今回考えているのは、そんな世界です。

映画 : ラスト・サバイバー (2026) / THE DOG STARS

はじめに

今年の劇場での映画鑑賞は、11回。

今回が12回目

原題と全然違う

観客は5人

原題が、「THE DOGS STARS」です。なんでこのタイトルかは、最後まで見ると分かります。。

たぶん、このタイトルのまま日本で公開したも全く人は入らないと思います。

日本での予告編

www.youtube.com

オリジナル版の予告編

www.youtube.com

全く同じです。

監督は、リドリー・スコット

  • エイリアン
  • ブレード・ランナー

の監督です。

プロダクションは、

  • Scott Free

ja.wikipedia.org

によると、

  • リドリー・スコット
  • トニー・スコット

の会社ですね。1970年創業。

映画の最初のこれを見たことがあると思います。

www.youtube.com

  • エイリアン
  • ブレードランナー

は、Scott Free ではありません。

Greensman

エンドロールに、

  • Greensman

なるものを見つけました。Gemini -san によると、

映画のエンドロールにおける「Greensman（グリーンスマン）」とは、撮影現場の植物や草木、庭園などの美術装飾を担当する専門スタッフ（植物担当）のことです。

のようです。

おわりに

この映画は、ウィルスにより人類のほとんどが居なくなった 2035年の世界です。ゾンビ映画ではないので、ウィルスに侵されてゾンビになったということではなく、遥か彼方の国からやってきたXXXにより、色々なことが起こるというお話です。

最後は、ちょっと、ハッピーエンドになるのですが、そこで、「THE DOGS STARS」になるわけですね。

最近の映画のエンドロール、メッチャ長いです。

ヒッチコックの映画では、オープニングに色々出てきますが、終わりはエンドロール無しです。

多くの人が関わらないと、映画ができなくなってしまったのでしょうかね。

今回の映画でも、数百人の名前は出ていたと思います。

AI半導体設計、第2回 : OpenROADの結果からAIにRTLを改造させる

はじめに

前回は、OpenROADそのものをAIに改良させるという話でした。今回は逆です。OpenROADの物理設計結果をAIに見せて、その結果からRTLを改造させる。

今までの方法

実は、これは半導体設計の現場では昔から行われています。RTLを書いて論理合成し、PlacementやRoutingまで進めてみたら、Timingが厳しい、Congestionがひどい、Bufferが大量に入る、といった問題が発生する。そうすると設計者はRTLに戻って修正します。

つまり実際の設計は、一方向ではありません。RTLからPhysical Designへ進み、そこで問題を発見して、またRTLへ戻るfeedback loopがあります。ただ、それを人間がやっている。

ここにAIを入れるとどうなるでしょうか。

AIにRTLを変更させ、SynthesisとOpenROADを実行する。Area、Timing、Congestion、Wirelengthなどを測定し、その結果をAIに返す。AIは「この変更は良かった」「Critical Pathがまだ厳しい」と判断して、さらにRTLを変更する。そしてまた評価する。

このループを何度も繰り返すわけです。

ここで重要なのは、「正しいRTL」と「良いRTL」は違うということです。Simulationが通り、仕様を満たしていても、PPAが悪いRTLはいくらでもあります。

例えばResource Sharingを増やせばAreaは減るかもしれない。でもTimingが悪化する可能性がある。逆に演算器を複製すればAreaは増えるが、Timingは改善するかもしれない。

つまりAIが探しているのは、単なる正解ではなく、複数の制約の中での良い設計です。そのため、PPAを一つの数字にするのではなく、Area、Performance、PowerなどのPareto frontierを見る方が自然です。

ただし、ここでも問題があります。RTL optimizationは評価するdesignにかなり依存することです。あるRTLで効いた変更が、別のdesignでは逆効果になることもあります。

だから、多数のdesignで実験する必要があります。そして重要なのが、成功例だけでなく失敗例も残すことです。「Pipelineを追加したらTimingは改善したがAreaが増えすぎた」「Resource SharingをやめたらPerformanceは上がったがPowerが悪化した」。こうした結果を蓄積していけば、AIは単にRTLコードを生成するのではなく、RTL構造と物理的な結果の関係を学べるかもしれません。

でも、ここまで考えると、さらに上の階層が気になってきます。

そもそも「このRTLをどう書き換えるか」ではなく、「このArchitectureで本当にいいのか？」という問題です。

MACを1個共有するのか、4個持つのか。SRAMを増やすのか、Memory bandwidthを増やすのか。Pipelineを何段にするのか。

これはRTLの書き方というより、Architectureの問題です。

おわりに

だったら、ここまでAIに探索させてみてもいいのではないでしょうか。

RTL optimizationの先に、Architecture Design Space Explorationがある。

次回は、そこまで話を上げてみます。