コンピュータの歴史を暗部も含めてていねいに掘り起こすことで定評のある大原雄介さんによる連載6回目。8bit版は残ったのに32bit版は消えてしまった、不運なAtmel AVR32の生い立ちとその結末について。
Atmelという会社とAVR（AVR8）というRISCプロセッサの話は以前こちらで書いた（*1）。今回の話はこれに続くものである。
*1：ついこの前書いたような気がしていたが、既に3年前の記事だった
Atmelという会社は1984年に創業された。社名は"Advanced Technology for MEmory and Logic"に由来する。創業者は元々はIntelでEEPROMの開発に携わり、次いでEEPROM専業メーカーであるSEEQ Technology（1999年にLSI Logicに買収された）を立ち上げたGeorge Perlegos氏である。
ついでに言えばそのSeeq Technologyの共同創業者がGordon Campbell氏であるが、CHM（Computer History Museum）に収録されたPerlegos氏へのインタビューによれば、VCとの関係がうまく行かなくなったということでまずCampbell氏がSeeq Technologyを去ってC&T（Chips & Technologies）を創業。これをPerlegos氏が後追いする形でやはりSeeqを辞めてC&Tに入ったものの、「何かが起きて（But somehow, I guess, something happened）」Perlegos氏はC&Tを辞任。そして立ち上げたのがAtmelということであった。
元々C&TはPC向けチップセットやグラフィックの分野のパイオニアの一社であり、実際Intelに買収されるまで様々な製品をリリースしていた（この話は以前ここで書いた）。
もう一つの特徴は、C&TがFabless企業のはしりだったことだが、これはPerlegos氏のアイデアだったらしい。そしてこれをAtmelでも繰り返すことになった。インタビューによれば「Fabを立ち上げる金が無かったから、必然的に設計に特化するFablessの形態でスタートせざるを得なかった」そうだが。
そんなAtmelの最初の製品は必然的にEEPROMであり、三洋やGI（General Instruments）に生産を委託していた。ちなみにGIへの最初の支払いに当たっては、当時Perlegos氏が住んでいた家を担保に金を借りて支払った、なんて話もインタビューには入っていた。
会社が軌道に乗るにつれ、新しい分野への参入も行われた（1987年にEEPROMの製造に関してIntelから特許侵害で訴えられたのも、この動きに拍車を掛けた）。1989年にはFlash Memoryの生産に参入するが、これに当たってはHoneywellがコロラドスプリングに保有していたFabを6000万ドルで買収、さらに3000万ドルを投じて設備を整え、同社の製造拠点となる（この時点でFablessから製造設備を持つFab liteに近くなっていた訳だ）。
1991年にはConcurrent LogicというFPGAのメーカーを買収してFPGAの製造にも参入、そして1994年にはMCU（Micro Controller Unit）の製造も手掛け始める。最初はIntel 8051互換というのは当時のMCUマーケットを考えれば実に妥当な選択で、先に生産を開始していたFlash Memoryと組み合わせることで、今では当たり前になった「Flash Memory搭載MCU」を割と早いタイミングで市場に送り出す事に成功した格好だ。
1995年にはArmとライセンス契約を結び、AT91シリーズのMCUを市場投入するが、こちらはまだARM7TDMIベース（のちにARM9ベースとかCortex-Aベースの製品も追加）で、売れたか？というとそれほどではなかった。ArmがMCUのマーケットを席捲するのはCortex-Mの投入以降の話であり、携帯電話向けとかを除くとまだそれほど大きな勢力ではなかったからだ。むしろその1995年に権利を買収、1996年から製品化を行ったAVRの方が同社にとって大きなビジネスになった。
この後も同社は幅広く製品ラインアップを拡充していく。Wireless（Sub1GHzと2.4GHz）とかタッチスクリーン、暗号化チップ、一部アナログなどである。この中で稼ぎ頭だったのがやはりMCUで、特に2005年にAVR8を搭載したATmega8をベースにArduinoが開発され、これが広まるにつれて爆発的に売り上げが伸びた。このArduinoの功績は大きく、「筆者が考える」（*2）3大8bit MCUの一角にAVRを押し上げることに繋がった。
*2：何をもって3大か？というと「現在も使われている8bit MCUのアーキテクチャ」である。いやこういうと「まだ×××の分野ではZ80が使われている」とかいろいろあるとは思うのだが、広範に使われており、製品も供給され続けているという意味ではPIC16・AVR8・8051の3種類だと筆者は考える。PIC18ではなくPIC16な辺りがミソ
ただその一方で、AVR8はどうやっても8bit MCUでしかないという限界も見えてきた。まぁそれはそうで、いかに効率が良いとはいえIn-Orderで32MHz程度のコアだから、処理性能も限界がある。そしてこの頃強力なライバルになっていたMicrochipは、MIPSのMIPS32 M4Kコアを搭載したPIC32を準備中だった。
ここで「ではCortex-Mをベースに対抗製品を作ろう」と判断していればまた違ったのかもしれない。実際NXPとかSTMicroelectronicsはこの当時からCortex-MベースのMCUをぼちぼち投入し始めている。ただこの時点ではCortex-Mが一大勢力になる、と判断するのは難しかったのは理解できる（筆者もこの当時、ここまでの勢力になるとは判断出来ていなかった）。そこでAtemlは、自社で32bitコアであるAVR32の開発をスタートする。
AVR32誕生
開発を担当したのはAtmelのノルウェーデザインセンターで、ここはノルウェー工科大学の出身者が多くいた。その意味ではAVR32もAVR8と同じくノルウェー工科大学由来、と言えなくもない。ただオリジナルAVRの設計者であるAlf-Egil Bogen氏とVegard Wollan氏は、少なくとも開発には携わっていない（どちらも既にAtmel社内で結構偉いポジションに就いていたから、もう参加させてもらえなかったのかもしれない）。こうして生まれたのがAVR32である。
実はAVR32には2バージョン（正確に言えば2アーキテクチャ、3バージョン）ある。最初にリリースされたのがAVR32Aで、こちらは2006年にAP7コアとして登場した。AVR32Aは低価格向けに簡単化した構造ではあるが、それでも7段のPipelineでALUとLoad/Store、更にMultiplyが別ユニットになっている、割としっかりめの構造である（Photo01）。
▲Photo01：2006年といえばTSMCがやっと65nmの量産を開始したことで、AVR32がどこのFabを使うつもりだったか不明（自社Fabは先端プロセスの対応が無かったから、どこか外部Fabだと思う）だが、もし自社Fabだとすると0.35μmとかのかなり古いプロセスを想定する必要があり、後述のように150MHzを狙おうとするとパイプライン段数をこの程度増やさないと追いつかなかった、というのはありそうな話である
このMultiplyが別ユニットというのは性能の問題もあるとは思うのだが、それより設計段階では「さらに小型化したコアにする場合、Multiplyを搭載しない」ことが簡単に出来るように、という配慮だったのではないか？という気もする。
このAVR32Aと命令セットが完全に互換で、さらに簡潔化したパイプラインを持ったのが2010年に登場したUC3コアである。ちなみにAP7が発表時の数字が150MHz駆動で210DMIPSなので、1.4DMIPS/MHz、500μA/MHzというスペックとなっている。
一方UC3は1.5DMIPS/MHzとパイプライン段数を縮めたにもかかわらずむしろ効率は良いのだが、その半面、動作周波数の上限はやや低く抑えられた。というかこのUC3になって、やっとまともなMCUになったというべきか。そもそもAP7を搭載した最初の製品の一つであるAT32AP7000のブロック図がこちら（Photo02）。
▲Photo02：これをMicrocontrollerというのはかなり無理があると思うのだが
何かおかしいとすぐに気が付いた方は、MCUを使い慣れてる人だろう。MCUと銘打っているにもかかわらずMMUを搭載、更に外部にSDRAMやSRAMを接続できるI/Fを持っており、逆にローカルメモリが無い（Cacheはある）。Pixel Coprocessorというのは一種のビデオアクセラレータで、これはまぁまだ許容可能だが、AC97のコントローラだのPS2のI/Fだのが並ぶに至っては、「これ本当にMCUなのか？」と疑いたくなるだろう。
実際これは既にMCUではなくMPUである。何でMPUの構成にしたか？正直なところは不明だが、恐らくAtmelはその前に投入したAT91が不調だったことと無縁では無かったように思う。先にも書いたがAT91シリーズはARM7TDMIコアを搭載したMCUであるが、MCUと言いつつEBI（External Bus Interface）を経由して外部に最大64MBまでのメモリを接続できる構成である。
それでもオンチップで最大128KBのSRAMとか128KBのROM（Flashにあらず）を搭載可能で、MCU的に使うことも可能だった。つまり外部メモリ無しでMCUとして使うことも可能だし、外部メモリを繋いでMPUとして使うことも出来る、という良いとこ取りを狙った構成である。
ただ、例えば初期の製品の一つであるAT81M40800シリーズとかAT81R40000シリーズとかは、たかだか40MHz駆動のARM7TDMIコアでしかなく、性能は0.68DMIPS/MHzだったそうなので27.2DMIPSほど。これでアプリケーションプロセッサにしよう、というのが土台無理であったのがあまり評価されなかった理由であろう。
そこでAtmelはこれをAVR32で代替するにあたり、性能を頑張って引き上げるために7段ものパイプライン構造にしたのだと思う。実際AP7ベースのAT32AP7000シリーズは150MHz駆動で210DMIPSなのだから、10倍とは言わないが7.7倍もの性能向上で、当時のローエンドのMPU向けとしては十分だったと思う。
ただその半面、当時の技術では150MHz駆動に耐えるNOR Flashは製造できなかったから必然的にROMは内蔵できず（Mask ROMなら搭載可能だっただろうが、流石にこの頃だとFlash全盛だったから、現実的にMask ROMを選ぶ顧客はいなかっただろう）、そうなるとMCU的な用途には不適当になる。結果MPU構成に全振りしてしまったにもかかわらず、何でこれをMPUではなくMCUと強弁したのかは謎である。
UC3は、今度こそMCUをターゲットとしたAVR32Aである。動作周波数はFlash Memoryが追い付く程度（66MHz）がターゲットとなるから、7段ものパイプラインが無くても十分カバーできるし、そうなると分岐ミスとかが発生してもペナルティが少ないからむしろ性能（DMIPS/MHz）は引き上げやすい。Photo03はUC3コアが出た後の製品のポジショニングだが、UC3ベースのAVR32はAVR8と同等の消費電力でより高性能、という位置づけになっており、やっと正しく製品が投入されたという感じだ。
▲Photo03：2010年頃のAVR32 UC3のカタログより。縦軸方向が明らかに変（この図に従えばAP7がUC3より省電力になってしまう）ではあるが、とりあえず横軸方向のみで見ればAP7とUC3のポジショニングが判るかと思う
ところで先ほど2アーキテクチャ、3バージョンと説明した。AP7もUC3もベースとなるのはAVR32Aアーキテクチャである。
厳密に言えば、AP7はオプションでFPUとSIMD/DSP命令、更にMMUとJavaアクセラレータ命令が用意されたのに対し、UC3ではDSP命令こそサポートされ、FPUはオプション扱い（ただし最終的に実装はされなかった）とされ、SIMD命令とJavaアクセラレータ命令、及びMMUの実装は無い（その代わりMPU：Memory Protection Unitが搭載された）が、基本的な命令セットは変わらないし、振る舞いもアプリケーションから見れば同じである。
もう一つのアーキテクチャがAVR32Bである。
こちらはリアルタイム制御を重視してか、より高速な割り込み処理が可能になった。例えばAVR32Aの場合、割り込みが入った場合はレジスタR8～R12の内容が無条件でSystem StackにPushされ、割り込み処理が終わると自動的にPOPされる仕組みが入っている。
プログラマーには優しい（?）仕様だが、こんなことをやってたらそりゃISRに飛ぶまでの時間が遅くなるのも無理はない。ではAVR32Bは？というと、Status RegisterとReturn Addressを保持する専用のレジスタが用意されるほか、Register FileのShadowing機能の追加、更にINT0～INT3の割り込みに関しては専用Register Fileが用意される。これによりISRに制御が渡るまでの応答時間を最小限に出来るというもので、このためにscall/rete/retsという専用命令まで追加されている。
なので通常の命令に関しては互換ではあるものの、OS（RTOS）などは互換性が無いというか、AVR32B専用のコードを書かないと性能が発揮できないことになる（実際には割り込みハンドリングの方法にも違いがあるので、互換性が無い）。加えて言えば、AVR32BではJava Virtual Machineを直接実行できる専用ハードウェアまで搭載していた（Photo04）。
▲Photo04：薄い色の部分が、AVR32BのJava Virtual Machineでサポートされる部分、濃い色の部分はAVR32AのJava Extension Moduleでカバーされる部分である
そんな訳でAVR32AとBの2つのアーキテクチャがある訳だが、実際にはAVR32Bを搭載した製品は、筆者が知る限り市場に製品としては出ていない。市場に汎用品として投入されたのはAVR32AのAP7コアとUC3コアのみである。
さて、Atmelは当初、このAVR32を全面に押し出していた。2008年にはこんな感じ（Photo05）で映像や音声のハンドリングをできることをアピール。
▲Photo05：ESC（Embedded System Conference）2008におけるAtmelのブースでの展示。手前の列車模型はともかく、その奥の人形らしいものはなんだろう？（もう覚えていない）
2009年にはUC3コアベースのEVK（評価キット）でMP3プレイヤーを繋いでMusic Stationを実装したり（Photo06）するなど力を入れていた。
▲Photo06：音楽の再生だけでなく、曲の選択とかもリモートで行える動作をデモしていたと記憶している
余談だがその2009年、ESCにおいてAtmelとMicrochipのブースが隣り合っていたあたりは誰の意図だったのか（Photo07）。
▲Photo07：左がAtmel、右がMicrochip。AtmelのブースはPIC vs AVRの比較を延々とモニターで流していた
AVR32に暗雲
さてそんな訳でAtmelは肝入りでAVR32を全面に打ち出していたのだが、2008年にはAVR32の開発と並行してArmからCortex-Mのライセンスを取得、2009年からまずCortex-M3ベースのSAM3シリーズ、2011年にはCortex-M4ベースのSAM4シリーズを市場投入。このSAM4シリーズが登場したあたりから、AVR32の雲行きがかなり怪しくなってきていた。
当初は66MHz動作の製品をメインに据えていたが、途中からLow Powerが売り文句になり（SleepWalkingという省電力技術を搭載したDシリーズの投入にあわせ、省電力性をアピールするように変わった。ちなみに動作周波数も最大48MHzに落ちた）、最後には1.8V動作（それまでは3.3V動作だった）のLシリーズが投入され、そこで汎用品の出荷は止まった。
そしてこの後AtmelはSAMシリーズを32bit MCUとして全面に押し出すことになる。実は2011年頃にAtmelの方にAVR32どうなったの？と尋ねたことがあるのだが、答えは「いやまだASIC用に提供しています」であった。
つまりAtmel自身がもうASIC用（つまりIPライセンスが必要ない分安価で提供可能）くらいしかマーケットが残っていないと見なしていた、ということである。
そして2016年にMicrochipがAtmelを買収した後、AVR8に関しては引き続きラインアップが残り、それどころかCIPs（Core Independent Peripherals）などMicrochipが持っていた技術を盛り込んだ新しいAVR8製品が市場投入されているにも関わらず、AVR32に関しては全く顧みられなかった。
そもそもMicrochip自身がPIC32としてMIPS32コアを入手しつつも持て余し、Armベースに切り替えを行っている（最新のPIC32はCortex-Mベースである）という状況でAVR32を必要とするはずもない。それでも組み込みメーカーらしく現在もUC3ベースのMCU製品の供給が続いている（例：ATUC128D3）辺りは流石ではあるが、AVR32の製品ページの説明は「以下のデバイスは当社の従来の32ビットMCU製品の一部であり、製品の需要が存在する限り可能な限り長期にわたって製品を供給し続けるという、顧客主導の陳腐化対策によるものです（The following devices are a part of our classic 32-bit MCU offerings and are backed by our client-driven obsolescence practice of continuing to supply a product for as long as possible and while demand for the product exists.）」なんてあたり、新規のデザイン向けに展開するつもりが無いのは明白である。
AVR32がどこで失敗したか？といえば多分企画段階であって、MPU向けに強化しようがMCU向けに強化しようが、結果から言えばArmのCortex-AやCortex-Mに勝てなかったであろうことは疑う余地がない。が、これは本当に結果論であって、2006年の段階でここまで見通せた人は世界でもほんの一握りであろうとは思う。
ただ、同時期にやはり独自のアーキテクチャを開発し、そして現在も利用されているRenesas RXという存在があることを考えると、もう少しやりようがあったかもしれない、とは思う。もう少し早く世に出ていれば、もっと愛されたアーキテクチャになれたかもしれないのに、とちょっと残念である。
