mac mini 2024とintel資産運用

前ふり

mac miniのARM移行については、DAW系ソフトとかも含め心配事が多いので踏ん切りがつかなかったのですが、mac mini 2024の超小型化に心動かされ、頑張って移行する事にしました。

一般ソフトの移行

最近のやつなら、ほぼUniversalでパッケージされていて、ARMで起動すればARM版が動いてくれます。万が一古いIntelバイナリだったとしても、Rosetta 2経由で快適に動きます。例えばVLCのビデオエンコードとかはIntelバイナリを変換して動かした方が速いくらいだし、Unreal Engineみたいな重たい開発環境でも、新しい版ならUniversal、古い版ならIntel版が快適に動いてます。

少し気にしないと行けないのがPlug-in系。例えば配信ソフトのOBSはVLCがインストールされてるとVLCを入力ソースとして選び、映像ストリーミングを受信したりできますが、お互いインストールされてるバイナリタイプが一致していないと拡張として認識されません。例えばOBSだけ最新版でUniversal、VLCはIntelって場合は、ARMに移行した時にOBSだけARMで動くようになり、VLCの拡張が利用できなくなります。このような場合、VLCをUniversalかARMに更新すれば連携できるようになります。もし両者をARMで揃えられない場合は、UniversalアプリをRosetta経由で強制的にIntelバイナリで起動するという方法もあります。

DAWやVST/AUの対応事情

DAWやDJソフトなんかはわりと早期にARM対応してたみたいで、今なら特に困ることなく移行できます。が、VST/AU周りは少しハマりポイントも。

VST/AUは基本的には先述のPlug-in問題と同じで、基本的にはアーキテクチャが一致してる事が望まれます。が、調べた範囲だとAUに関してはOSレベルでクロスアーキテクチャをサポートしてるので透過的に使えるらしく、全てのDAWでサポートされてると思って良さそう。VSTに関してもDAWごとに内部的にブリッジ用意して使えるように努力してくれてます。

FL Studio ... この辺で説明されてるけど、ARM版で起動してもIntel VSTをブリッジしてくれます。Intel AUは少しはまりポイントがあったので後述。

Cubase ... VST3はARM版しかサポートせず。VST2に関してはIntel版もブリッジしてくれます。古くて移行してくれてないやつはだいたいVST2なので納得感ある、かつ公式らしい対応。

Studio One ... 2でも3でもIntel VSTをブリッジしてくれる。

AUに関しては落とし穴があって、読み込み時にシステムダイアログで警告を受けます。

ここでうっかりゴミ箱に入れないようにしましょう。「このまま開く」から許可する手順に入ります。すでに具体的な事はわすれてしまったけど、もしかしたら左のダイアログが先に出て、人まずは完了でパスして、この後にシステム設定に設定項目が現れて、そこから許可をすると右のダイアログで許可できるようになったかも。システム拡張とかパーミッションの設定と近いプロセス。

で、落とし穴は、このダイアログがでない環境があるって事。自分のケースではFL StudioではSynth1は黙殺されてましたが、Studio Oneでこのダイアログが表示され、そこから承認プロセスを通したらFL Studioでも使えるようになりました。

あと、マシン移行時にライセンスの再認証が必要なPlug-insが多いと思うので注意しましょう。自分の場合、iZotopeの再認証をしてなかったため、Studio Oneで定期的に音切れが発生する、という現象に悩まされてました。

新規仮想マシンの運用

もし一般的なWindowsアプリが動かしたい場合は、Parallelsか無償になったVMware Fusion経由でARM版Windowsを動かすのがおすすめ。ARM版Windows自体がIntelバイナリを実行する機能を持っているため、大半のソフトは問題なく動きます。問題が起きるとすれば、特殊なドライバを必要とする開発系ツールなど。あとはゲームでアンチチートに弾かれる事はあります。最近の需要で言えばVRChatが該当します。かつては問題なく動いていましたがEAC導入後は弾かれてます。VCRChatに関しては公式から非公式情報が出ており、エミュレーションするハードウェアの固有値をうまく設定する事で回避できるようですが、ARM版Windowsのバイナリ変換ではこの辺の固有値は設定できないので対応不可と思われます。

Linuxに関しても、今はARM版LinuxからRosetta 2経由でIntel版アプリを動かす事もできるようになってます。という事で、いずれの場合の新規OSインストールが許容できるなら、ARMベースで動かしてアプリレベルで必要に応じてIntelバイナリを変換、というのがパフォーマンス的にもベスト。

Intel仮想マシンの移行

すでに運用してたIntel版Windowsをそのまま持ち越したい、という需要が大きいとは思うんですが、ビジネスでそれをサポートしてくれてるとこは残念ながらありません。今のところ、そこそこうまく言っているのは、UTMでqemuのバックエンドを使い、Intelシステムエミュレーションの上で変換したVMイメージを使う方法くらいです。以下、注意点をいくつか。

事前にParallels関係のVM補助ツールは全部アンインストールしましょう。残っていると他のVMに持っていった際に関連ドライバ（prl_strg.sys）が起動中にクラッシュします。

Parallelsのディスクイメージは、snapshotとったりサイズ可変の設定になってたりすると変換がうまくいきません（サイレントに壊れて、起動失敗したところで深く悩みます）。元のマシンでこれらの設定をはずしてから、 /Applications/Parallels Desktop.app/Contents/MacOSts/MacOS/prl_convert などを使ってplainなフォーマットに変更しましょう。そこまで変換しておけば、UTMでファイルを選択した際にqcow2形式に自動変換した上でVMのフォルダ内にコピーを作ってくれます。

UTMに持ってきたら、CPUのマルチコア設定に注意。qemuはマルチコアエミュレーションをする際、コアごとに別スレッドでエミュレーションをするので物理スレッド数くらいまでエミュレーションするCPUを増やせばスケールするはず！と思うと失敗します。ARM上でIntelをエミュレーションするのは、strong-on-weakと呼ばれるケースに該当します。要はマルチコアにおけるメモリ一貫性保証の制約がARMの方がパフォーマンスを出しやすいweak memory orderを採用している。その上でより制約の厳しいstrong memory orderをエミュレーションするのは難しい/オーバーヘッドがでかいです。そのため、デフォルトでは正確性を優先してマルチスレッド対応は切られてる。そこで、システム設定にある「マルチコアを強制」にチェックを入れると、memory consistencyのサポートは諦めてマルチスレッドで動くようになります。この設定を受け入れないと実用的な速度では動きません。qemuの方でも一応バランスを見てバリアを埋めてくれてはいるようで、実用上は問題にはならない気はします。実際、ARM版Windowsのバイナリ変換でも標準設定でははmemory consistencyは壊れてます。実行ファイルのプロパティにある互換性設定でバイナリごとにエミュレーション精度を指定できるようになっており「標準設定でうまく動かなかったら、ここを変えてね」という扱い。一方Rosetta 2に関してはApple Silicon側にstrong memory orderをサポートする仕掛けがあり、正確かつ高速なエミュレーションができている、と言われてます。ほんと夢がある石なんだよ……。

Windows 10のイメージを持ってくるのに使ってる設定は以下の通り（いじったとこだけ）。

アーキテクチャ: x86_64
システム: Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-9.1) (q35), 8192MiB
CPU: デフォルト, 4コア, マルチコアを強制
QEMU: 「ベースクロックにローカル時間を使用」のみチェック（非UEFI環境）
ディスプレイ: virtio-vga-gl (GPU Supported)

Linux系を持ってくる場合もParallels用のドライバは削除した方が良いみたい。GPU Supportedなディスプレイカード設定を入れると画面が落ちるのは古いせいかと思ってたら、どうもParallels用のドライバが悪かった。/Applications/Parallels\ Desktop.app/Contents/Resources/Tools/prl-tools-lin.isoあたりをマウントしてinstallerを実行すれば、uninstallが選べます。これでUbuntu22でvirtio-gpu-gl-pci (GPU Supported)が動くようになった。それまではvmware-svgaしか動いてなかった。virtio-ramfb-gl (GPU Supported)がいけるという話もあるけど、自分は動かなかった（けど、Parallelsの掃除してからは試してない）。

既存のVMイメージの流用だけじゃなく、どうしてもIntel版Windowsが必要って場合もUTMで同様の設定で新規インストールするのが唯一の解だと思います。新規の場合はギャラリーにあるイメージが最適設定の参考になるかと。VRChatのハードウェア設定もUTMで設定いれればワンチャン動くかもしれません（未確認）。

Wine

そうそう、Wineryとかwine系ラッパーで作ってあったパッケージはそのまま快適に動いてます。たぶんRosetta 2経由で起動してる。

その他

何から何まで移行・動作確認できてるわけじゃないので、他にも色々とあるかも。

例えばbrewとかはARMだとインストールする場所が変わるので、intel版残したままARM版も入れて様子見てる。

VS Codeの拡張とかもintel依存多いので怪しい。たぶんログアウトして同期を切ってからアプリとデータを削除、再インストールするのが正しい……けど、やってない。同期したままファイル消したりすると伝播するので危険……というのは以前経験した。

VRChat動かしたい人は、ARM版LinuxでRosetta for Linuxを使ってSteamを動かせば、Proton経由で動く可能性がありますね。少なくともSteamDeckではProtonでEAC突破できてるので。

追記（2024/12/31）：Rosetta for Linuxはx86_64しかサポートしてない模様。Steam Launcherが32bitアプリなので一工夫必要。i386だけbinfmtにqemuを登録するとか？と思って試してみたけど、最終的にはlibGLの中で落ちた。

ここまでは動くんだけどlibGLまでいってcrashしてしまう。流石にこれは無理か。
そういや、RosettaもGUIは駄目なんか？と思ったけど、nethack-x11とかVLCは動いてるな。Chromeは流石にcrashした。 pic.twitter.com/aNEI0oQRm9

— とよしま (@toyoshim) December 30, 2024

試したい人向けにやった事のメモをしとくと、UTMでGalleryにあるDebian 12 (Rosetta)をインストール、その中で以下の作業を敢行。

sudo apt install qemu-user-static
sudo update-binfmts --install qemu-i386 /usr/bin/qemu-i386-static --magic '\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
sudo dpkg --add-architecture i386
sudo apt update
# https://store.steampowered.com/about/ から steam_latest.deb をダウンロード
sudo apt install ~/Download/steam_latest.deb
steam

Xに垂れ流してた作業ログを簡単にまとめただけなので、もし詳細を教えて欲しい！ってとこがあれば、Xで声かけてください。分かる範囲でなら答えたり追記したりします。

齧って逃げた子、誰だ〜

だ〜れ〜だ〜。
最近あやち聴いてばっかり。

佐藤さんのFPGAのコミュニティーに顔を出しておきながら、めっきり論理設計してない私。論理設計屋さんからソフト屋さん転職して早4年。そろそろ何か書かないと勘を忘れそうなので、ちょっとリハビリしてみました。

まずは家のリポジトリ漁って、使いまわせそうなやつを集めてGitHubに共通モジュールとして突っ込んでみたのが一週間前。なんかもうISEインストールして、今更なSpartan 3 Starter Kit（しかも無印）で動作確認するだけでぐったりですよ。だって今時パラレルポートとかないですもん。しかもUSB変換器じゃ駄目っていうJTAGお馴染みの問題。さらにUbuntuが新しすぎてドライバがインストールできないとか、おーのー。ここに時間かけるくらいならZynq買ったほうが安上がりだった。玄人志向のPCIとか買ってる場合じゃない！

で、とりあえず最近おなじみ、かつお手軽そうな6502でも実装してみるか、と。とにかく昔のCPUなんで今時のCPUとは違う楽しみがあるかもな、とか思ったわけです。で、いきあたりばったりで一気に書き上げてみたんですが……そうとうなカオスコードになってしまったorz 今にも書き直したい気分だけど、面倒って気持ちの方が大きかった。

このくらいなら手書きでデコード論理組めるだろー、とか甘く見てたんだけど結構ぐちゃぐちゃ。これだったら素直にcase文でパラの線にバラして、論理圧縮は合成ツールに任せたほうがマシだった。
あとやっぱり面倒だったアドレッシングモード。本家のマニュアルにアドレスバスに出てくるパタンが説明されてるので、だいたい中でどう動かしてるのか想像つくんだけど。なんか計算途中のゴミアドレスをバスに流してて気持ち悪い。こんなんでメモリマップドI/Oとかホラー過ぎる。で、資料がある故に厳密に倣って作ってみたんだけど、いろいろとチグハグにならざるを得なかった。やっぱり当時は資源共有して最小限の論理数で作ることに命かけてるんで、そこはあえて同じこだわりで設計してみた。
モジュール間のインターフェースもエンコードするかバラして流すかってのは悩むんですけどね。FFに突っ込むにはエンコードしといた方が資源節約になるけど、CPUの場合せっかくデコードしたのになー、みたいな気持ちもあって。今回は中途半端にエンコードしたままにしたせいで、条件がいろいろ複雑になってしまった。
でもまぁ、マイクロコード以前のCISCがどんな感じで作られてるか体験する良い機会にはなった。

まぁ、来年はApple IIをグラフィック込みで動かすくらいはやるかもです。

あ、ちなみに合成するとXC3S200で論理21%、FF 3%くらいの使用率。もっとFF使っても良いですね。800ロジックセルだから、あてにならないゲート換算で1万ゲートくらい？綺麗に書き直せば500ロジックセルくらいまで減らせないかなぁ。

ARMの上で動くリンゴ印のOSで究極のLチカを楽しむ

ARMは仕事で初めてゲームを作ったコンシューマ機、ゲームボーイアドバンスのCPUという事で、とても思い入れのあるCPUです。ゆんゆんに「ちょっと手伝ってー」と言われて立ち寄ったのが今や泣く子も黙る神移植のM2さん。タイトルはデ・ジ・キャラット。楽曲は憧れの並木学さん。そしてサウンドプログラムを手がけていたのがX68k界でブイブイ言わせてた齊藤彰良さん。当時はお二方ともM2移籍前。僕もワクワクしながら仕事をしていました（最近は大きな仕事に慣れすぎてワクワク感が麻痺してしまってるかも……）。
そんな思い入れのあるARMですが、今やモバイルを中心とした組み込み世界の覇者。AndroidやiPhone向けの高性能プロセッサであると同時に、ホビー向けには個人でも100円程度で手に入るモデルが沢山あります。そこで、せっかくだから久々に何か遊べないかなー……という事で考えたのが……

120円ARMの上でリンゴ印のアイツを動かす！

そう、あれです、あれ。Apple II。
秋月で手に入るLPC1114の性能を見ていてピンと来ませんか？

• ARM Cortex-M0
• 50MHz（最大）
• Flash: 32KB
• RAM: 4KB

このギリギリ感！ちなみに以前からマイコンだけで古のマシンを再現する企画を続けており

• CP/Mega88 ... CP/M Z-80 on ATMEGA88 (20MHz, Flash: 8KB, RAM: 1KB) + 外付けSRAM 64K
• MegaZ-80K ... MZ-80K on ATMEGA644 (20MHz, Flash: 64KB, RAM: 4KB) + ATMEGA328 (20MHz, Flash: 32KB, RAM: 2KB) + TINY2313(20MHz, Flash: 2K, RAM: 128B)

に続く第三弾です。ソースはgithubに置いてありますが全てアセンブリで書かれています。毎回何かしら無駄な挑戦をしているわけですが、今回の見どころは

1. I/O 4KB、ROM 12KB、RAM 48KBをFlash 32KB、RAM 4KBだけでごまかす
2. ビデオ出力とキーボード入力をUARTのTX/RXに変換する
3. 空いてるI/OにGPIOを割り当てて、Apple BASICからLチカ

の3点。

1は単純なローテクで実現。ROMはFlash側に埋め込み、VRAMについては一切記憶しない事でメモリ節約（次節でも説明）。ゼロページやスタック、Apple BASICが本気で使う空間にはRAMをまじめに割り当て、それ以外の領域に関しては全部同じ1-Byteを共有するようにしてあります。主記憶のないキャッシュみたいなもんで、書いて読んで比較……という単純なメモリチェックに対しては正しく動くけど、本当にワークとして触りだしたら動きません。まぁ、初期化コードを騙して、小さいプログラムを動かすには十分。

2は気合。UART入力をキーボードに変えるのは比較的簡単ですが、出力をUARTに変換するのはちょっと大変です。VRAMへの書き込みを見はりつつ、前に書いたアドレスからの差分でカーソル移動を行います。書き込み内容はTXに送るだけでVRAMの実体は実装しません。読まれたら固定値0xFFを返すだけ。スクロール時の画面書き換えは書き込みパタンから自動判別します。読んで１段上のラインに書き込んで……という処理を繰り返すのでアドレスパタンからも判別できるし、本来使われることのない"読み出し値0xFF由来の値"の書き込みを検知する事でも判断できます。スクロール処理中は再描画の書き込みを無視し、スクロール終了を検出したらしれっと改行を送って通常モードに戻ります。

3は特に難しいことはなく。拡張スロット用のI/O空間が開いているので、そこへのアクセスをGPIOにつなげてみました。Apple BASICからはPEEK/POKEで気軽に全メモリ空間へアクセスできるので、これだけでBASICからGPIO制御が可能になります。

という事で簡単なデモ。YouTubeの編集機能使って音とか説明つけてみた。携帯片手に左手でぽちぽち入力した映像なんですが、フラフラしてた画面も手ぶれ補正であっさり安定。

という事で、次はこのプロジェクトを始めた真の目的、佐藤一憲さんにもらったWIZnetを繋げて遊ぶ、というステップに進もうかと。宿題間に合いそうで良かった、良かった。

CPU Emulation using JIT on JavaScript

I'm struck with an idea to implement CPU emulation using JIT like technique on JavaScript. Basically, the emulator generates JavaScript function which emulate a target binary sequence by the basic block, then cache it in hash. The code could be like 'cache[pc] = eval(jit()); cache[pc]();'.

Since I'd like to know how this technique could be effective, I just make a tiny pseudo emulator and estimate its performance. The result show the JavaScript CPU interpretor will be x100 slower than a native code. Modern JavaScript engines become faster and faster. But it seems to be still slow. On the other hand, qemu-arm seems to be quite fast. It's just several times slower than the native one. So how about my emulation using JIT on JavaScript? It's slower than qemu. But not so bad. It might be pretty fast than native CPU interpreter.

As supplements, I must say that this benchmark treats just one simple case and the result will be changed by loop size, count, and JIT overheads in various situations.

久々にCPU関連のサーベイ - Survey on CPU Top Conference

ひとまず去年のISCA、MICROで面白そうな論文ないかなー、ということで選ぶだけ選んでみた。まだ読んでないので、すでに読んだという人がいたら教えてくれると嬉しいです。
For the time being, I took a glance at the last ISCA and MICRO to catch up. I just choosed interesting papers and not already read. If you know following papers, please  teach me the essence :-)

分野的にも興味あって面白そうなやつ。
Papers which I'm interested in and on which I would like to research.

ISCA 2010
 - Translation Caching: Skip, Don't Walk (the Page Table)
 - NoHype: Virtualized Cloud Infrastructure without the Virtualization

MICRO 2010
 - Architectural Support for Fair Reader-Writer Locking

少なくとも当面は手を出しそうにないけど面白そうなやつ。
Papers being interesting, but I wouldn't start on just yet.

ISCA 2010
 - High Performance Cache Replacement using Re-Reference Interval Prediction (RRIP)
 - The Virtual Write Queue: Coordinating DRAM and Last-Level Cache Policies
 - Morphable Memory System: A Robust Architecture for Exploiting Multi-Level Phase Change Memories

MICRO 2010
 - Synergistic TLBs for High Performance Address Translation in Chip Multiprocessors
 - ASF: AMD64 Extension for Lock-free Data Structure and Transactional Memory

Spacewar!

しばらく前に作ったDEC PDP-1のエミュレータをベースにActionScript（Flash）版のエミュレータを作ってみました。せっかくのFlash版なので表示はそれっぽく・・・と思ったのですがセンスが足りないためイマイチな表示になってしまいました。

太古のマシンなわけですが、表示が1024x1024の解像度があり、残像やらボカシやら縮小やらで、表示系がずっしり重たい処理になってしまいました。エミュレーション自体はたいした事ないんですけどね。。。後でソースを1つにまとめてWonderflにも投稿したいと思います。

ちなみに動いているのはSpacewar! 知っている人は知っていると思いますが、世界で最初のテレビゲームと言われている物です。パンチカードの情報をデジタル化したファイルがありまして、そいつを読み込んで実行しています。

個人的な目的としては、プリプロセッサを使ってC++向けのコードとActionScript向けのコードを共通化する実験とか、版管理ツールとしてMercurialを使ってみる実験とか。

追記：さっそくWonderfl向けにカスタマイズして投稿してみました。

Spacewar! (DEC PDP-1 emulator) - wonderfl build flash online

The Benchmark Handbook

ベンチマークについての古い資料で、昔はウェブで無料公開してたものらしいんだけど。今は公開サイトのドメインも失効してしまい、Morgan Kaufmannから出てた書籍も中古（しかも、わりと高価）でしか入手できない・・・と思ってたんだけど、試しにweb.archive.orgにかけてみたら、PDF含めてしっかりと残ってました。

というわけで、The Benchmark Handbook Online版。たまに論文に出てくるThe Wisconsin Benchmarkについて、それなりに詳しく書かれた唯一の資料でしょうか。

ハードウェアプリフェッチ

ハードウェアプリフェッチの分析方法としてSrinivasanらによるPTMT: Prefetch Traffic and Miss Taxonomy(*1)という手法が有名です。古典的な評価では、Coverage（本来ミスだったメモリアクセスの何割がプリフェッチで救えたか）とAccuracy（プリフェッチのうち何割が有効なプリフェッチだったか）でしか評価してなかったわけですが、PTMTではプリフェッチを行った場合と行わなかった場合の両方のケースについて同時にシミュレーションを行い、プリフェッチにより取得したキャッシュライン、プリフェッチにより追い出されたキャッシュラインそれぞれがキャッシュヒットとなったか、あるいは追い出されたかを調べて分析します。例えばあるプリフェッチにより取得したキャッシュラインがヒットしたとしても、追い出したキャッシュラインがミスを引き起こしてしまっては意味がないわけです。

これがマルチプロセッサ（SMP）環境になると、キャッシュのコヒーレンス制御が影響してきます。プリフェッチにより早期にデータを取得しても、その後のリモートプロセッサのストアによりせっかく取得したキャッシュラインをINVALID化する必要があります。このような効果も考慮したのがJergerらによるMPTMTと呼ばれる手法(*2)です。

さらにマルチコア（CMP）の場合にどうなるかというと、これはちょっと複雑で、キャッシュを共有する効果ってのも考える必要が出てきます。SMPの時のようなコヒーレンス制御の影響より、アグレッシブなプリフェッチを行った際の汚染の影響の方がクリティカルになるので、CMPならではの新しい問題、というよりはシングルコアの頃に研究されていたキャッシュのAccuracyを高めるといった手法が効果的になってくるみたいですね。そんなわけで、プリフェッチをフィルタリングして最小限度の質の高いプリフェッチを発行する、というのがプリフェッチ研究の1つの柱としてあるようです。プリフェッチのターゲットアドレス、あるいはプリフェッチを発行したPCをキーとしてプリフェッチが有効だったか否かのヒストリーをとり、そこから先は分岐予測と同じストーリー。やっぱりgshareとか使うと良い結果が出たりします(*3)。学習が入ってくるとなると、学習の種としてPTMT的な分析手法も重要になってきます。実際にインプリできるハードとして、1回の実行でどれだけ効果的に学習できるか、ですね。ちょっと前にキャッシュのセット方向の情報を使って１回の実行で様々なキャッシュサイズを想定したミス率変化グラフを書くって手法を聞きました。なんか同様のうまい方法を思いつかないかなぁ・・・なんて考えてたりしますが、一朝一夕にはいきません。

整数系のベンチマークでは、RDS: Recursive Data Structuresに着目した研究成果(*4)もあります。リストとかを辿る処理を検出して先読みする類いのやつです。この手の構造体のポインタを読み出すLoad命令をIPL: Induction Pointer Loadと呼ぶらしいです。なんか、アーキテクチャ屋さんにとっては紛らわしい略語ですね。この手の研究は学生の頃にもちょろっと調べた記憶があります。Sohi先生のとこでもやってたような。こっち方向の研究はあまり筋がよくない事が多いですよね。

*1: A Prefetch Taxonomy
*2: Friendly Fire: Understanding the Effects of Multiprocessor Prefetches
*3: Reducing Cache Pollution via Dynamic Data Prefetch Filtering
*4: Characterization of Repeating data Access Patterns in Integer Benchmarks

POWER6の物理設計

あまり新しい話題でもないですが、IBM Journal of Research and DevelopmentにてPOWER6の特集が組まれていまして。その中でも気になっているのがIBM POWER6 microprocessor physical design and design methodologyって記事です。

図2に設計フローが紹介されているんですが、これによればPOWER6はVHDLで論理設計を行っているんですね。今までゲートレベルで設計していたプロセッサメーカも徐々にRTL設定にシフトしてるって事でしょうか。

面白いのが、RTLへ移行したタイミングで周波数が一気に上がって、でも複雑なOoO制御は止めて・・・という、直感とは違う結果が出ていること。後者は電力から来る要求で、そもそもアーキテクチャをダイナミックに変更できたというのがRTLの成果なのかもしれませんが。周波数に関しては、ゲートレベル設計が有利というのはもはやアセンブラプログラムが速いってのと同様の幻想なのかもしれません。

System z10の特集はまだだけど、同じような傾向があるのでやっぱりRTL設計なのかな。

気迫と勘だけで作ってる某社とは違って、きちんとサイエンスしてるな、と思います。

追記：設計フローの基本はPOWER4の頃から変わってないとの事で、POWER4の特集を調べたら当時からVHDLで論理設計をしているようでした。ただ、物理設計周りの人手でやっていた部分がだいぶ自動化されたようですね。