Arria GX

テーマ:

選手権が終ってデジカメで撮った写真やアキバで買って来た部品を整理してたら、突如Alteraが新製品を発表、更にQuartusIIもVer7.1となって、ここ数日そっちにハマってしまった。


本家の発表:http://www.altera.co.jp/corporate/news_room/releases/products/nr-arriagx.html

EETIMES Japan:http://www.eetimes.jp/contents/200705/18145_1_20070509111714.cfm
Tech-On!:http://techon.nikkeibp.co.jp/article/NEWS/20070508/132148/?ST=lsi

今年の6月から量産出荷となっている。本当にそうなら開発キットもその頃に手に入らないと納得行かないが。で、Arria GXは基本的にStratixII GXの廉価版という感じで、I/Oピン数およびトランシーバチャネル数と対応しているプロトコルに制限を付けて差別化しているようである。ロジックの性能はStratixIIとほぼ同じ。


QuartusII Ver7.1のダウンロードはこちら(Arria GXに対応している):

http://www.altera.co.jp/support/software/download/sof-download_center.html

今日インストールして試してみたが、とりあえず過去に作ったプロジェクトは支障なくビルドできたので無問題。で、Arria GXの開発キットが995usdとなっている。日本の販代を通すと\140k~150kくらいになると思うものの、ちょっと早めに注文を入れてみようかと思っているところである。

AD

CycloneIII

テーマ:

ここのところ本業モードに入っていて殆ど更新してないのにも関わらずアクセスが爆発していたので原因を調べてたら、"CycloneIII"でググられてのリンクだったようだ。このブログが無意味にトップに来てたのにはビビった(汗) 因みに"Cyclone III"でググると下位。僅か1文字スペースがあるか否かでここまで検索結果が違うというのも、微妙に問題がある気はする。それはともかく。


アルテラの本家HPでは既にアナウンスされているが、やはり最先端計数将棋学的に書いておかねばなるまい。モノ自体は07/03/20に発表されていたようである。完全に本業に入ってたので全然気が付かなかった。


本家:http://www.altera.co.jp/products/devices/cyclone3/cy3-index.jsp

ASCII24:http://ascii24.com/news/i/hard/article/2007/03/20/667856-000.html

MYCOM journal:http://journal.mycom.co.jp/news/2007/03/20/540.html

Tech-On!:http://techon.nikkeibp.co.jp/article/NEWS/20070317/129062/


CycloneIII アプリ開発に対応したQuartusII Ver7.0が既にリリースされているので試してみようと思っている。ダウンロードセンタはこちら→http://www.altera.co.jp/support/software/download/sof-download_center.html


因みにCycloneIIIのスタータキットが\19k-。評価レベルでしか使えないが、ちょっとFPGAなるものを勉強してみようか、という方にはお奨めする→http://www.altera.co.jp/products/devkits/altera/kit-cyc3-starter.html

(但し、毎度のことながら発注してもすぐには手に入らないと思われる)

AD

StratixIII

テーマ:

重複してしまうが、最先端計数将棋学的に書いておかねばなるまい(笑)


http://www.altera.co.jp/corporate/news_room/releases/products/nr-s3release.html
http://www.altera.co.jp/products/devices/stratix3/st3-index.jsp
http://www.altera.com/literature/br/br-stratixIII.pdf


ES品が来年第3四半期出荷と少々未来の話になっている。但し、設計だけならQuartusII Ver6.1を使って今からでも可能だ。明日の選択肢のひとつとして最先端野郎に謎電の作者はこのデバイスを推奨する。
少し話は逸れるが↓のアナウンスの意味の判る方は、完全に業界通だ。


http://www.altera.co.jp/corporate/news_room/releases/products/nr-gigabeat.html

AD

Alteraの次期FPGA

テーマ:

既に古い記事('06/06/05時点)なのだが、とりあえず。


ASCII24 Business Center:http://biz.ascii24.com/biz/news/article/2006/06/05/662653-000.html

日経BP Tech-On!:http://techon.nikkeibp.co.jp/article/NEWS/20060605/117838/


本家HPでは未だ何のアナウンスもないので微妙に疑問が残るが、Virtex5と同様に2007年量産開始予定のようである。↑記事ではStratixIIIについてのみだが、他所の情報ではCycloneIII(廉価版)も同時期発表になるようだ。


【追記】 全く余談ですが。もはや価格を尋ねる気にならなくなる程のASICエミュレーション用マルチFPGAボード、特に SON of MONSTER。これ一枚でHydraを軽く超えれます(笑):http://www.applistar.com/dini/index.html

StratixII PCI Express カード

テーマ:

一応は本家から開発キットを出したようだ。


日本語:http://www.altera.co.jp/products/devkits/altera/kit-pciexpress_s2gx.html

英語:http://www.altera.com/products/devkits/altera/kit-pciexpress_s2gx.html


使っているデバイスは、StratixII GX EP2SGX90F1508C3[*1]。お値段は$2,995-でChrillyの探索コアなら4個は入る規模。個人的には2SGX130+Express x16が欲しかったのだが、とりあえずコレも視野に入れておこうと思う。今後サードパーティから色々出てくると思うので少々待ってみるつもり。


既にScience Geek!! でコメントしたのだが、性能的に不利感があったXilinxはVirtex5(65nm)をアナウンス した。量産は未だ先のようではあるものの、少なくとも現StratixII(90nm)よりは良さげである。Alteraが65nm版でどう巻き返すか、謎電の作者は注目している。


[*1] 型番の最後の"C3"はデバイスのスピードグレイドを示している。 この場合、StratixIIの最高グレイド品であることを意味する。因みに現Hydraは、Xilinx VirtexIIPro XC2VP70-5を用い55MHz動作だが、このStraatixIIだと、(熱対策が充分であれば)ほぼ倍速の100MHz前後で動かせる筈である。あくまで「Chrillyの探索コアが」だが。計算上は、このカード1枚で旧Brutusと同等かそれ以上の性能が出せることになる(旧Brutusは、33MHz動作の4DualFPGAで8cores)。

StratixII GX のサンプル出荷開始

テーマ:

個人的に期待していたStratixII GXの出荷がやっとアナウンス された。と言ってもサンプル出荷でしかないし、受注を開始した開発キットも評価レベルのボードなので使えないのだが、将来的にトランシーバチャネル数が16以上のモノが出てくれば、PCI Express x16[*1]に対応したFPGAカードが出てくるだろうと思う。


具体的には、EP2SGX90Fか2SGX130G。量産開始が今年の10~11月の予定なので、実際にPCI Express x16のカードが出てくるのは来年に入ってからになるかも知れない。間に合えばそのあたりのデバイスを使って第17回で4coresハード探索をやってみたいと思っている。その前の第16回でSPEARを倒さないとな(笑)


[*1] 1レーン片方向あたり2.5Gb/sなので、x16で40Gb/s=5GB/sがピークの転送速度だが、実ピーク帯域はその20%減の(8B/10Bエンコーディングが入るので)、片方向あたり4GB/s、双方向で8GB/sとなる。とはいえ実際には転送速度より応答速度の方が重要だったりするし、ドライバだけでなくアプリレベルのプロトコルの設計次第で通信効率は相当変わる。

汎用Multi-FPGA PCIカード

テーマ:

最近、超ハイエンドFPGAカードを知ったので紹介しようと思う。

左のFPGA カードは、GiDEL というFPGAボードプロバイダが出しているFPGA4個搭載PCIカードPROCStarII である。詳しい諸元についてはHPの方をご覧になっていただくとして、Altera StratixII EP2S60~180までチョイス出来るプロダクトのようである。

2S180[*1]×4だと、そのお値段はR34GTRの新車価格くらいになるようだが、Chrillyのように32セットの古い「Xeon+FPGAカード」を買うよりは安いし、巧く制御出来れば、これ1枚で現Hydraと同等のパフォーマンスは出せそうだ。

今の私には全く手が届かないとしても、最終目標の4~5年後には使ってみたいカードの有力候補である。それまでに等価性能の物が1桁安くなって、せめて(最低でも)133MHz PCI-X Rev2.0 mode1か、(もはや別物だが)PCI Express x16くらいのバスI/F[*2]にして欲しいところだ。いや、今やAGP[*3]が空いているので、それでも可だが。結局バスのボトルネックを克服出来るかどうかは、プロトコルを含めた通信のノウハウと、低水準I/Oにも手を入れる(つまりはデバドラから作る)覚悟があるか否かだと考えている。


[*1] 因みに2S180は2C35の約5倍の規模の回路を組める。以前にも書いたが、このFPGA1つの中にChrillyの探索コアが8個入るしその上速い。熱対策を施せば基準クロック100MHz前後で安定して走れる筈である。

[*2] この手のバス規格はとてつもなく奥が深い。例えば、133MHz PCI-Xと言っても2枚挿しすれば100MHzでしか使えないし、4枚挿しすれば66MHz駆動になる。セカンド・オピニオン第40回 から(今日現在では)第144回まで「バスのアーキテクチャ - 過去から未来へ」が連載されている。興味がある人にとっては面白いコラムだと思うのでご覧になることをお奨めする。

[*3] バス幅は32ビットだが、8倍速モードで2.13[GB/秒]の帯域を遊ばせておくのは勿体無い気がする。


I asked the impression of this card to Marc. He said: "The GiDEL board looks very nice, I see no reason why it would not be good for you, as long as the fpgas are big enough (I don't know Altera much). However, a first step will be to get a single engine working (that fits in a single fpga hopefuly); the parallel engine can come after." Thx for your advices, Marc.

アービタ改造 (1)

テーマ:

下に示すソースは、Marcの指手生成器の中のarbiter.vだ。これは、アービトレータ(Chrillyが言うところのコンパレータツリー)を構成する一部品で、指手生成器のクリティカルパスに大きく影響する回路である。ハード探索処理を構成する全てのユニットの中で、指手生成器が最もクリティカルパスが長いとするなら、このロジック如何で探索速度が決まる極めて重要なコンポーネントと言える。


--*** CodeBlue Chess ***
--Arbiter circuit implementation
--------------------------------------------------------------------------------
--fpga express implementation: 20 lut, 0 ff
--replaced if priority structure by comparison
--fpga express implementation: 18 lut, 0 ff
--optimization effort high, optimize for area
--fpga express implementation: 17 lut, 0 ff, 20.64ns delay
--redid priority circuit by hand, optimize high, speed
--fpga express implementation: 16 lut, 0 ff, 14.42ns delay

--tests to perform: noted by "optimize" comment
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
--use ieee.std_logic_arith.all;

entity arbiter is
port (
    invert_pri: in std_logic;
    arb1_in, arb2_in: in std_logic_vector(2 downto 0);      -- (2 downto 0)
    rowcol1_in, rowcol2_in: in std_logic_vector(5 downto 0);--x2,x1,x0,y2,y1,y0
    arb_out: out std_logic_vector(2 downto 0);              -- (2 downto 0)
    rowcol_out: out std_logic_vector(5 downto 0));
end arbiter;

architecture rtl of arbiter is

signal muxval,agtb: std_logic;

begin
--process for agtb
process(arb1_in,arb2_in)
begin
    if arb1_in>arb2_in then
        agtb<='1';
    else
        agtb<='0';
    end if;
end process;

--process for mux_val
process(arb1_in,arb2_in,invert_pri,agtb)
begin
    if invert_pri='1' and (arb1_in/="0000") and (arb2_in/="0000") then
        muxval<=not agtb;
    else
        muxval<=agtb;
    end if;
end process;

--process for arb_out and rowcol_out
process(arb1_in,arb2_in,rowcol1_in,rowcol2_in,muxval)
begin--optimize: try explicit values instead of mux
    if muxval='1' then
    --if arb1_in>arb2_in then
        arb_out<=arb1_in;
        rowcol_out<=rowcol1_in;
    else
        arb_out<=arb2_in;
        rowcol_out<=rowcol2_in;
    end if;
end process;

end rtl;

ソースの冒頭近くにあるMarcが書いたと思われるコメントを見ると、当時の開発環境(恐らくISEの古いバージョン)で合成した時、16LUTsを消費し14.42nsの遅延があったようだ。但し、この数字は昔のデバイスとは言え遅過ぎるので、多分入出力ピン-LUT間遅延も加算されているものと思われる。でなければ14.42ns×6(チェスの場合6レベルツリー接続なので)=86.52nsとなり、アービトレータだけでここまで遅延が大きいと、まともな速さでは走らない計算になってしまう。


さてこの回路は、駒コード3ビット×2つの入力を比較し、価値の高い方、あるいは逆に低い方を判定し、その駒位置を含めて駒コードを出力する、というものである。これをQuartusII 5.1で合成してRTL viewerで等価回路図を機械的に作らせたのが左下図だ。更にtechnology map viewerを使って作図させ、下中央がStratixIIの場合、右下がCycloneIIの場合の実装上の回路図になった。StratixIIとCycloneIIでtechnology mapが異なるのは、同一メーカでもFPGAのアーキテクチャが微妙に異なる為である(特にLUTの)。

RV-cmn051216 TVstr2501216 TVcyc2051216


1つのアービタのみに着目すれば、実装上のロジックレベルはStratixIIで2、CycloneIIで3となり、アーキテクチャの違いによる性能比が3:2になることが判るが、ここでは参考例として挙げてみる。回路の具体的な遅延時間は、プロセスは勿論デバイスのスピードグレイドに依存する。1ロジックレベルあたり0.5nsと仮定すると1つのアービタの遅延時間は単純計算でStratixIIで1.0ns、CycloneIIなら1.5ns。これをこのまま将棋用の指手生成器に使って強制的に7レベルツリーで接続してアービトレータを構成した場合のクリティカルパスは、StratixIIで7ns、CycloneIIで10.5nsとなる。が、元々64桝のチェスの為に作られたアービタを、81桝の将棋用として無理矢理用いるのは多少無駄がある。そこでこれを将棋用に最適化することを考えてみる。

-- 多分、次稿は来年頃に続く --

先日のDeepJuniorの記事には、ぶっちゃけこっちが挫折しそうである。Juniorの作者である Amir Ban と Shay Bushinsky のソフト屋としての威信と存亡を賭けた、それとも単なる意地なのか、Chrillyに対する挑戦状のような数字を見せつけられると、コンピュータチェスの世界も実に面白いものだと思う。


兎に角、Chrillyの探索コアの実効500万局面/秒程度という数字では、既にあまりに旧仕様で魅力に欠けるパフォーマンスになってしまっているということだ。その一桁上の(1FPGAあたり)実効5000万局面/秒くらいが実現できないと、ハード探索に本気で手を出す気になれない。それはコンピュータチェスでの話だが、計算機将棋の世界であってもその数字は変わらないような気がする。


さて以前Chrillyは、1FPGAあたり2つの探索コアを載せようとして巧くいかなかった。しかしそれは「物理的にも論理的にも出来ない」話ではない。単にデバドラを書かなかっただけの事のように思うし、それ以前に「最新最強のデバイスを使ってない」という突っ込み所もあって困る。そのあたりの技術的に解決可能な問題やコストに絡む部分に対していちいちミソをつけてもしょうがないのでそれは置いといて、謎電の作者的今後の方針と計画を少し書こうと思う。


以前書いたことでもあるが、やはりFPGA側でもマルチコア化は必須だと考えている。これはコスト(コア単価)を下げるということが主目的だ。とりあえず試作では4つのコアを1つのFPGAに入れたいと思う。具体的には詰探索コア×2+指将棋探索コア×2という構成である。詰探索コアはPN系探索、指将棋探索コアは残2手+静止探索の予定。これは、少し理由があってそうした。


初期の机上検討では、詰探索と指将棋探索を1つのコアでどちらでも探索モードを指定して使えるようにしたかったのだが、そういうゴージャスな仕様のコアでは規模が大きくなりすぎて4つ載せるにはコストが掛かり過ぎると判断した為だ。寧ろ機能を限定(専用化)した方がコアを小規模化、且つ動作周波数を上げることが出来、よりハード資源の利用効率を上げられる可能性があると踏んだからである。


このあたりは実際に作って動かしてみないと何とも言えないし、だからこそ試作なのだが、2007年に開催されるであろう第17回選手権までにはなんとか間に合わせたいと思っている。(最終目標ではなく)試作レベルでの目標は、とりあえず実効1000万局面/秒/core、稼働率90%で合計3600万局面/秒を最低ラインとするつもりである。もっと具体的に言えば「ライエル問題集」なら1問1分制限で80問以上の正答を目指す。


しかし、それでもSPEARに勝てない


てなことなったら面白ろ悲し過ぎるが、そこまで謎電の作者の人生は呪われていないと私は信じている(笑)

-- 完 --

謎電の"with FPGA"計画。現時点では、机上検討とcomponent単位の試作までしかやってないし、性能目標も満足が行くというところまで達してはいない。しかしながら、少なくとも現Hydraよりは1桁コストパフォーマンスを改善出来る物が実現できそうな目処だけは立ちつつある。Hydraが占める主コストは、第一にXeon+FPGAを32(64)組使っている点、第二に光LAN環境にある。現Hydraの性能と等価相当のシステムを、


・フルタワー型PC1台の規模で実現し
・そのマシンの総重量は30[kg]未満とし
・その消費電力を1[kW]未満に抑える


と、低コスト・高パフォーマンスであることだけでなく、小型・軽量・省電力と運用レベルまでを考慮している。一見ズレた目標や制限に見えても、その設定がなければ目的から逸脱した物を作ってしまいかねないからである[*1]


さて、アーキテクチャとしては、マルチプロセサ/マルチ探索コア構成を考えている。現HydraやDeepBlueと同じであるように見えて異なる点は、CPUと探索コアが固定的な1対1対応、あるいは1対多対応というものではなく、多対多対応型で一言で言えば、CPUと探索コア間に(電話の)交換機が入っているようなイメージだ。これが意味するのは、実稼働率重視型システムを目指している、ということである。


DeepBlueでは、30CPUで1CPUあたり16コアという構成。30×16=480個のコアを用いて並列探索させても、その稼働率はHsuの言に拠れば1/5程度と悪い。またHydraではChrillyの言を信じれば約80%だ。しかしこの80%というのは、探索コア(FPGA側)の稼動率を意味しており、そのコアを制御するCPU側は、逆に約20%程度の実稼動率しかないと考えられる(一対のCPU-FPGAが排他的にしか働いていないことを前提とするなら)。つまりは32(64)個のXeonのうち、その約80%は遊んでいるのと同じということだ。システムとしては単純で結構だが、本当にそうならコスト掛け過ぎの感が否めない。


現HydraでFPGA側が探索している最中、その処理が終了するまでCPUは単に割り込みを待っているか、あるいはポーリングしているだけの単純な機構で動いているのなら、先に書いた通りCPU側稼動効率はかなり酷い。このあたりの制御メカニズムについて具体的に明かされていないので、実際超エエカゲンなのではないかと穿っている。また、それとは別件だが、ChrillyはしきりにPCIバスのボトルネックを問題として挙げている。それは間違ってはいないが正しくもない[*2]


PCI/PCI-X を正しく良く知る為に次の2冊は必読。これらをChrillyがちゃんと読んでるのか甚だ疑問で、PCIバスを批難する前にまず読まれることをお奨めしたいところである。無論、PCI-XをCPU-FPGA間通信用のバスとして使うつもりがある全ての開発者に対して、でもある。


・Edward Solari, Ed Solari, George Willse

 Pci and Pci-X Hardware and Software: Architecture and Design


・Tom Shanley

 Pci-X System Architecture (PC System Architecture)

-- 続く --


[*1] Hydraのような物理的に巨大なシステムを一人で全部対局場に運んだらギックリ腰を起こしそうだし、電源事情が悪ければ参加を遠慮しなければならなくなりそうだからだ。このあたりは個人的な職業上の拘りなのでどうでもいいことに思えそうだが、優先順位は高く設定して検討した方が後々(運用時に)問題が起き難い。
[*2] 以前書いたことの繰り返し。現Hydraで使われている光LANは、1000BASE-T(IEEE 802.3ab)より速いし応答性も良いことは間違いないが、PCI-Xバスより遥かにボトルネックの筈だ。なぜならば、そのLANのI/Fカード自体がPCI-Xバスを使っているのだから。これを問題としないのは、恐らくスポンサに遠慮しているのだろう。