Spansion、Freesacleの車載向けVybridと連携する音声処理プロセッサを発表

先月の話になるが、6月19日(米国時間)に米Spansionは新しく「Acoustic Coprocessor」を発表した。この6月19日という日付は、米Freescale SemiconductorがFTF Americas 2012において車載向けVybridを発表したタイミングでもあり、要するに車載用VybridにこのSpansionのAcoustic Coprocessorが組み合わされる形でインフォテイメントシステムへの投入が行われる事になるからだ。

予備知識として説明しておけば、Vybridとは2011年11月にFreescaleが発表した、Cortex-A5コアとCortex-M4コアを組み合わせた新しいプラットフォームである。当初は名前も決まっていなかったが、2012年4月にはこのプラットフォームをVybridという名前でまず民生及び産業向けに投入する事が発表されており、6月の発表はこれに続くものである。

このVybridにAcoustic Coprocessorが加わる理由は、音声での操作に対応するという話である。ちょっと旧聞になるが、2007年からFreescaleはFord MotorsおよびMicrosoftと共同で、"Sync"というシステムの開発を行っている。このSyncの中には音声認識/合成が含まれており、ハンズフリーのまま音声だけで操作を行えるようにするというもの。当時はこのSyncのシステム向けにはARM11ベースであるi.MX31が利用されていた。

Cortex-A5コアはARM11に比べると「それなりにパワフル」であるが、元々がARM11に比べて同一周波数で20%程度の性能改善を目指したコアだから、動作周波数の違いを考慮しても絶対性能で2倍の差が出るかどうか…というあたり。その一方で音声認識の精度改善にはより多くのCPU性能を必要とする。加えるならば、多機能化・高機能化が進む昨今のインフォテイメントシステムの場合、音声認識をやっている最中であっても同時にやるべきことは多く、音声認識に専念する訳にはいかないから、音声認識の精度を上げつつもCPU負荷を下げる必要がある。これを実現するために、多くのベンダはより高性能なコア(Cortex-A9のDual/Quad Coreなど)を投入する方向性を示しているが、Freescaleのアプローチはちょっと違う、という訳だ。

前書きが長くなったが、そんなわけでSpansionのAcoustic Coprocessorである。この製品の最初のターゲットはPhoto02の通り、車載インフォテイメントシステム向けである。音声認識というマーケットそのものは車載以外にも多く、例えばiOSのSiriとかGoogleのGoogle Voice Searchなどは、原則として特別なハードウェアも必要とせず、しかもそれなりの精度を確保しているのは利用した方ならご存知の通り。ところがこうしたクラウドベースのサービスは、あくまでネットワークが常時接続されているのが前提になるから、車載向けだと「トンネルに入ったら電波が切れたので音声認識できません」となってしまいかねない。言うまでも無くこれは論外であって、このため「当面車載向けに関してはローカルで処理できるシステムが絶対に必要」(同社Director of Segment MarketingのRobert Fan氏)としている。

ではこれをどう改善するのか? がこちら(Photo03)。

今回のSpansionのCoprocessorは外部に接続される形になるが、これによって必要とするメモリ帯域やFlash容量を減らせるため、システムの効率を上げられると共に、より多くの辞書を搭載できるために精度の改善が可能、という説明であった。非常にラフな試算としては、CPUの負荷を半分に減らしながら、レスポンスタイムを半分に短縮できる、としている(Photo04)。

では具体的にどんな形でこれを実現するか? 一般に音声認識の場合、まず音声を取り込んだ後、フィルタリングなどをしてからサンプリングをする。ここでサンプリングした音声をデータベースを参照しながらスコアリングし、そのスコアを元に文章を復元する、という仕組みをとる。この3段階の過程の中で一番処理負荷が高いのがAcoustic Scoreing、つまりサンプリングした音声の波形をデータベースと比較してスコアリングする部分である。そこでこの部分をCPUからオフロードすることで、CPUの負荷を減らすことが可能、というのが同社の説明である。

加えて言えば、Application Processorにこの音声データベースを搭載した場合、メモリあるいは検索時間の制約から、巨大なデータベースを搭載することは難しいし、全件検索はもちろん不可能であって、Nearest Matchに留めざるを得ない。ところがCoprocessor側にこうした処理を分担することで、より多くのデータをより精度良く検索することが可能になる、としている(Photo06)。また将来的には、より多くのデータベースを用意することも可能であり、これも精度改善に役立つと説明している(Photo07)。

SpansionによるAcoustic Coprocessorそのものの説明はこの程度であったが、もう少し細かい話を聞くことが出来たので、以下補足説明。

まずなぜSpansionはCoprocessorの分野に乗り出したか? というと、同社のNOR Flashの技術が使えるからという事だそうだ。今回の場合、Coprocessor内部のAcoustic Databaseには同社のNOR Flashが利用されているそうである。同社としてはNOR Flashのアプリケーション用途をさらに広げてゆくための様々な模索をしており、その1つがこうしたApplication Processorという訳だ。なのでPhoto07に出てきた辞書の拡張というのは、同社からすればより多くのNOR Flashを利用してもらえるということになり、NOR Flashのマーケット拡大という目的にも適うし、アプリケーションの精度向上というメリットにもなるわけだ。

で、その問題のCoprocessorの中身であるが、最初に聞くと「Hard WiredのAcceleratorで、汎用のCPUとかDSPではない」という説明だった。ところが「では検索アルゴリズムの変更とかフィルタリング方法の変更とかがあっても対応できないのか?」と聞くと、それは「ファームウェアアップデートで可能」という話であった。このアルゴリズムそのものはNuance Communicationsの技術であり、なのでもしNuance側がアルゴリズムを変更したりした場合は、Coprocessorもそれに対応できるような仕組みになっている、としている。どうもここから察するに、FPGAというかReconfigurable Processor的な仕組みを取り込んでいるか、あるいは内部はいくつかの機能ブロックに分かれた形でHard WiredのAcceleratorが搭載されており、これの繋ぎ方を小さなMCUあたりで制御できるとか、そんな感じの構成になっているのではないかという印象を筆者は受けた。

ちなみに同社としては当面他のCoprocessorを手がけるという予定はないそうで、もし次にあるとすれば、現在はAcoustig Matchingのみを行っているが、これを広げてフロントエンドのDSP処理とかバックエンドのSearch Engineまでカバーするような製品になるのではないか、という話であった。

またNuanace Communicationsと組んだ理由としては、「Nuance Communicationsはこの業界のNo.1であり、すでに膨大なクライアントが同社のソリューションを利用しているから」(Photo08)という話であった。

もともと同社は(競合メーカーが殆ど無いこともあり)自動車業界でのシェアは非常に高く、新規製品であっても受け入れられやすい関係を築いている。今回の製品はそんなわけで自動車マーケットが最初のターゲットであり、コンシューマ向けはやや後回しになると思われる。実際コンシューマ向けであればSiriなどの様に「ネットワークに繋がっているときだけ使えれば良い」(ネットワークに繋がってないと使えなくても仕方が無い)というソリューションでも受け入れられやすく、Coprocessorを追加することで製品コストが上がるのは許容されにくいと思われる。とはいえ、「オフラインでも使えて精度が高い音声認識というニーズは車以外にもある」という事だそうで、こうしたマーケットに対してもこれからは拡販してゆきたいという話であった。