不定記　[exa5]　

Spring Processor Forum 2005レポート〜さまざまなDSP搭載プロセッサ(その2)
TarariがデザインしたワンチップコンテントプロセッシングASIC、T9000が。
…ただこの記事の説明はどうも混乱してしまってる箇所が散見されるような…
元々TarariのContent ProcessorはFPGA上にプログラムされたもので、ASICとして初めてデザインされたのがこのT9000なのだと思いますが、この記事以外にT9000にふれているところを見つけられなかったので、いつもよりさらに3倍適当に書くことにします（じゃあほとんど推測ですらないじゃんというつっこみはスルーさせていただく方向で）。

Controllerなどは、既存のTarari CPと同じものを指していると仮定してみると、パラレルプロセッシングのため機能特化型のEngineである各AgentをGPPとすると、ControllerもGPPな気が。少なくともDSPじゃあないと思うのですけれど。ControllerがParsingしながら広義のスケジューリング（Chaining Control含む）をしているわけで、それがDSPならCompress/Decompressなんかも思いっきりDSPだと思うのですがどうでしょう。というか暗号化関係と圧縮・伸長Agentは普通にDSPに入れてもいい気がします。所謂Layer7のProcessingをHardware CodingにしたのがContent Processorなわけで（Anti-Virus Content Processing ASICなんてのが一番数が出てるのでは。FortiGateがたしかそういうアーキテクチャですから）、各Element/Agentの実装種別を決めたものではなく、だからGPP+DSP…という括りに入れられないでCool ProcessorなんてRadicalさだけで放り込まれるようなところに放り込まれてるというべきか。
FPGA版と同じXOE(XML Offload Engine)なFunctionだとすれば、処理する（ロードされた）XMLドキュメントのデータ部分をC/Java経由でのXPathを使ったアドレス指定でランダムアクセスが可能だったり、お馴染みのSOAPメッセージを勝手に処理してくれたりすることができるはずで、それらのコントロールを行うControllerがDSPというのも考えにくい、というか、それDSPっていうんでしょうか…
(XOEについてはAcceleration Techniques for XML Processorsなどを参照。ただしRAX-CP と同じと仮定しているので、Schema ValidationもHardware側でOffloadするはずです）

まあぼくにはよくわかりませんのでここら辺で放り出します。


InterQoSのMPは、まあ自前とかプロプリエタリである必要がないからそうしたのかなぁ、とか思ったり。
というかInterQoSって現存のProduct自体はNetwork ProcessorでもアシストだけするNetwork "Co"Processor専門で、あと元々Customize/Optimizeサービスにフォーカスしてるので、その延長線上でサービスでペイするモデルを打ち出したのかなと思うのです。まあ適当すぎですけれど。

ところで一番下の方で触れられているLEONですが、このスライドに"Space Invaders"と書かれているのはやっぱりLEONがESAの手によるものだからでしょうかね。いやどうでもいいっちゃいいんですが。

ってInfrantのNSPってRISCコアと書かれていたけれど、LEONだったんかい。知らんかった。

…まあSPARCベースじゃそんなにEco-Systemが大きい訳じゃないのでコアIPがGNU GPLベースになってもあまり積極的なメリットがあるわけでもない気がします。てか0.13μmプロセス以降で回路を「実装」して「マスクつくって」、さらに「量産」することの各々の障壁を考えるとサポートというか人材というか、資金というか、その、ねぇ…どうなんでしょう。