May 2008 Archives

知らないうちに、押し入れの天袋に女性が住み着いていた、という事件があったわけですが。
BBC に出てる!

そりゃ衝撃的だよなあ...

クソ忙しい生活をしている間にジロもいよいよ終盤。

でも、Richard Ricco が総合2位なんだよ。
ちょっとロードレースに興味ある人でも、誰だよそいつ? という感じの人もいるかもしれないんだけど、彼は前にジャパンカップで宇都宮を制した男なのだ。ジャパンカップでは正直、日本の選手に勝ってほしいと思っているが、だが、それ以上に宇都宮の山を制した奴がジロを制する、という展開は盛り上がるじゃないか。

何もなければアスタナを応援してたと思うのだけれど、リッコとなれば話は違う。

どうか、勝ってくれ!
仕事があるので中継見たりしてるほどの余裕はないが、決して君の名前は忘れない。

最近超マジメに仕事して熱中しすぎて、若干昼夜逆転気味だったりして、メールの返事とかが滞りがちだった (ご迷惑をおかけしております) のを、今朝は気合いを入れて早起きして、一気に修正した。

で、研究室でモリモリ仕事してたらボスに、「最近元気ないんじゃないかと思って心配してた」といわれた。いや、久々に仕事に熱中してただけですよ。わはは。

何をやっているかというと、昔書いたあまりきれいじゃないコードを一気にクリーニングするという作戦であり、つまり、昔の俺のプライドをなるべく傷つけない (=なにしろ、全部書き直したら死ぬほどの量になるんだ!) ようにしつつ、今後の保守性を確保できる美しさを手に入れる、という大作戦なのだ。

いやしかし、なんでこんなコード書いたかね。やっぱり急いでたんだろうな。

My cycling map, more to come (but I'm lazy...):

http://maps.google.com/maps/ms?ie=UTF8&hl=ja&msa=0&msid=102027596352263209352.00044dd02176794c6beda&ll=37.913258,139.069448&spn=0.008972,0.020084&z=16

「300万くらいで人生を変えてみる」という Audi 認定中古車の広告。
ふーん、と思った。

自動車はねー。

持つと持たないではけっこう違うけど、持たなくたって免許をもっていれば、ときどき借りればいい、と思う。もちろん、自分で持っていれば好きなときに (夜中に突然、とかでも) 出かけられるから、ちょっといいなー、と思うことがある。いい車とそうじゃない車は、結局のところ快適性とかの違いであって、もちろん高い車は静かだったり、運転が圧倒的に楽だったりするから、運転してみると、あ、これいいな、と思うけど、でも、頭を殴られるほどの世界観の変化、ではないような気がする。

もっとも、NSX とかポルシェとかに乗って飛ばせる腕があるなら、そういう車を持つか持たないかは、けっこう違うかもしれませんが。でも、自分のではないにしろ 100 万の車も 400 万の車も運転してみて、結局のところ 200km/h とかで走る環境も技術もないなら、やっぱり fit くらいで充分楽しいよなー、と思う。

300万かけて自動車買うことがあるか、といわれたら、一生ないような気がする。

何がいいたいかというと、つまり、10万円のロードレーサーのほうがはるかに衝撃的で楽しい乗り物だ、ということだ。

ママチャリという不思議な文化のある日本に育ってしまって、20年以上もこの乗り物に乗ることがなかったことと、既にプロロードレーサーを目指せる年齢ではなかったことを、心の底から悔やむくらいに。

あ、でも、誰かが変なバックグラウンドなしに、純粋なプレゼントとして自動車くれたら、喜んでいただきます(笑)。俺、そんなに人に感謝されるような生き方してないから、絶対ないけどね。

それから、最近思うのだが、ロード乗りになったのが大学院に入ってからで、本当によかった。うっかり中学生とかで乗り始めてたら、絶対人生踏み外してたと思う...

新潟駅から会津大学まで、国道49号線を延々と走ってきた。

大きな地図で見る

前半は概ね阿賀野川沿いで、新潟あたりの平野を走るうちは平坦コースなのだが、強烈な向かい風に体力を削がれる。国道49号だと遠回りになる部分があって、川沿いの県道でショートカットしたのだが、ここは余計に風が強くて、参った。しかし、大型車も少なくて、ずっと田んぼの間でのんびりした雰囲気で、いい感じだったよ。

磐越道と出会うあたりから49号に戻ると、じわじわ上りがはじまり、向かい風との相乗効果でかなりきつい。勾配はそれほどでもないのだが、最近ずっとサボっていたツケが回ってきたのかもしれない...

三川まで上り坂。落石避けのトンネルを必死に抜けると平坦で、津川まで 10km、川沿い。阿賀野川はとんでもなく川幅が広く、絶景。津川には漕艇場があって、昔は川港として栄えたそうだ。

55km も走ったし、しばらく山が続きそうなので、津川のバス停で一休み。「きつねの嫁入り屋敷」なんかもあった。保育園に行く子供たちや、お母さん、おばあちゃんたちが話しかけてきた。自転車で新潟から会津まで行くなんて！という感じ。津川は街並みも渋い感じだし、景色もきれいでいいところだ。また来てみようと思った。

津川から西会津まで15kmくらいの間に、峠ふたつコンボ。非常にしんどい。峠のてっぺんにはトンネルがある、というのが新しい道の定番で (古い道の場合は、よほどのことがないかぎりトンネルなしで山を越える。天城峠とか笹子峠の旧道はてっぺんにトンネルがあるが、まあ、これは昔から大きな街道だったからね)、これが見えるまでがとにかく辛い。いつおわるかわからない上りが延々と続くわけで。コーナーを抜ける度にこれで終わりか? と期待しては裏切られる、その繰り返し。今回は荷物もかなり多かったので辛くて、景色を楽しむほどの余裕は全然ない。幹線道路で交通量も多いしね。
トンネルは、中に水が溜まると困るので、大抵入り口が上りで出口が下りになっており、道幅も狭いので交通量が多いと前半は必死。とにかく怖い。まあ、テールライトつけてるし、勾配もそれまでの峠道よりはずっと緩いので、スピードもけっこう乗るから大丈夫ですが。

西会津の道の駅で休憩。オートバイで旅行中のおじさんとちょっと話す。まだ峠があるよー、といわれた... オートバイはいいよなあ。楽だもんなあ。会津若松からきて、今日はこれから新潟へ出て、寺泊のあたりで泊るそうだ。明日は只見へ。いいね！ 13 時が迫ってきているので、早めに出発。11:30 くらい。

会津坂下までの間に峠がふたつあるのだが、ひとつめの峠がかなりきつかった。途中で休もうとして右足攣ったし。ふたつめはトンネルでぶち抜かれており、楽勝。トンネルを抜けると会津坂下で、あとは平地なのだが、完全に脚が売りきれており、25km/h がやっと、というありさま。会津大には 13:10 くらいにたどり着き、なんとか最初の発表の途中から聴くことができた。

景色もよかったし、休憩している間に色々なひとと話せて楽しかったよ。
でも、今日はもう走りたくない...

111.97km @ 22.4km/h (4h59m18s) odo 4725.4km

[ 部分回路再構成を利用した耐故障性向上アーキテクチャの提案とその実装 ]

壊れたブロックを置き換えたときに、壊れてるところから配線に信号が行っちゃわない？
大丈夫だそうです。

[ 高精度浮動小数点演算器のFPGAでの実装 ]

倍精度だと CPU と勝負するのは厳しいが、四倍精度だと CPU でも emulation になるので、四倍精度の演算器が FPGA にいくつか載れば、CPU に勝てる可能性がある!

乗算は仮数部の下の方とか捨てちゃってもいいよね。
加減算はシフタが巨大になる... 絶対値の比がものすごく大きくて情報落ちが発生するような状況でなければ、多少サボれる。

[ 部分再構成システムにおけるAES-GCMを用いたビットストリームの秘匿と認証 ]

認証暗号 (AES-GCM) を使って、秘匿と認証を同時に行う (2000年くらいから出てきた概念)
Altera は Stratix IV GX で部分再構成に対応らしいぞ!

AES+SHA より小さくて速くなった。

[ FPGAにおける標数5の楕円曲線演算の高位合成を用いた実装 ]

楕円曲線ってソフトウェアでもRSAなんかと比べて遅いの? はい、とても。まだ実用化されてない。

[ ディジットシリアル演算を導入した ]

[ MXコアのMIMD型PE間データ通信における経路決定手法の提案 ]

SIMD から MIMD にして、逐次処理でも性能が出るようになったが、制御が大変。
PE 間のデータ通信も SIMD 的に、全部の PE が同じことを同時にやるのではなく、個別に指定できるようにしたい。

[ A Link Removal Methodology for Application-Specific Networks-on-chip on FPGAs ]

X-Y routing より難しいルーティングを提案してるけ、もう少し賢い、大きな (面積を食う) ルータが必要？
source routing なので、そんなことはない。

[ 粒度可変論理セル向けクラスタ構造の一検討 ]

ALU: 算術演算に向く
LUT: 論理演算に向く

これがデバイスによって規定されてしまうのは都合悪い。2入力標準型とFAをくっつけたロジックセル。
いままではセルをそのまま並べていたのをクラスタ化する検討。
クラスタ化自体の効果は？　ローカル配線による性能向上がでてるだんだけど、スライドはありません。。。

[ RapidMatriX: Algebraic Path Problemのための 2D array processor ]

Algebraic Path Problem: グラフ理論みたいなやつ。
2D SIMD array
3入力1出力の複合演算器。FMA のほかに大小比較やブール演算を含む複合演算を実行。

[ パワーゲーティングを適用した動的リコンフィギャラブルプロセッサの設計と評価 ]

斉藤くん。

電源の GND に高閾値電圧のスリープトランジスタを入れて、ブロックまるごとを殺すのが従来のやりかた。粒度も大きいし、wake-up にも時間がかる。
宇佐美研ライブラリはローカルな GND を作って、そこにスリープトランジスタを入れる。細粒度で制御することができて、 wake up < 5ns。損益分岐点をちゃんと計算していれてやらないといけないのと、ネットリストを加工して挿入しなければならないのがちょっと問題。

全体でリークが多いのは ALU と SMU. Pickout は小さなモジュールで、あまりリークしないので、削減効果は少ない。
ALU + SMU を同時に sleep/wakeup するのと、別々に制御するのと検討した。同じくらいの利き方のときもあるが、後者の方がズバッと効くこともある。面積オーバーヘッドは 7-14%.

レジスタファイルってけっこう大きいから、レジスタファイルを残してほかのところを削ってもだめなんじゃない?
それは心配したんだけど、実は ALU のほとんどは乗算で、それが結構大きいので、意外と大丈夫です。

[ 銀塩ホログラムメモリを用いたマルチコンテキスト・ダイナミック光再構成型ゲートアレイ ]

いままでの光再構成型ゲートアレイは、SPD に FF がついていた。新しいのは、SPD の接合容量を使って SPD 自体をメモリとして使うことで、FF を排除する。面積は減るんだけど、バックグラウンド光が入ったりすることで回路の保持時間が短くなったりするのが心配。

いままでは液晶をホログラムの代わりにしていた(簡単だし)。こんどは銀塩を使います。銀塩だと、ホログラム作成装置が必要。He-Ne レーザ (633nm) で書き込み。コンテキストあたりの面積は液晶の 1/4 以下。

AND 回路を作ってみた。configuration に 69ms で、回路を維持できる時間は 189ms.
ただし、いまは He-Ne レーザーがつきっぱなしで、それがバックグラウンド光の原因にもなっているのを、半導体レーザーとかにすればもっと回路を維持できる時間を延ばせると思う、とのこと。

SPD の面積は LUT とかに比べるとどれくらい？ (ふんがさん)
ひとつ 25.5um 角のを使ってるので、すごく大きい。でも、最近の SPD は 1um 角くらいにはなる。

銀塩ホログラムって一枚いくらくらい？ (尼崎先生)
数千円くらい。最終的には銀塩じゃなくて、 3D なホログラムを使いたい。

光学系が大掛かりで製品化は難しそうだけど？ (NEC 梶原さん)
パッケージに入れるような場合には、チップ自体からレーザーを出して反射させるようなやり方もありで、将来的にはもっとコンパクトに作れると思う。

[ 4コンテキスト光再構成型ゲートアレイによる高速再構成 ]

いままでに出せた最短の再構成時間は 41.7ns.
構成を高速化するにはコンテキストの輝度を高くするのが簡単。単純にこれをやるのは高出力レーザーだが、かわりにコンテキストの明点のビット数を減らすことにした。電力と過熱の問題を回避できる。
反転フォトダイオードを用意して、コンテキストのビットをぽちぽち書き換える方式。

He-Ne で全体を構成し、半導体レーザーで部分再構成。

10コンテキストあったらすべてのコンテキスト間での遷移の差分 (90パターン) を用意するのは大変じゃない?
実用的には LUT のパターンを書き換えることが多いだろう、ということでこうしている。
全体を書き換える方法ももちろん考えています。

[ FPGAを用いたストリーム処理に基づくステレオ画像の特徴点抽出法の検討 ]

小栗先生。

ストリームによるリアルタイム処理で観測・認識・動作を一体化する。
ロボットビジョンでは「とりあえず」メモリに全部データをおく、というのが前提になっちゃっているんだけど、これをやめましょう。カメラからの映像をそのままストリーム処理で分析して、カメラの位置を変えたりする。
メモリのバンド幅の問題とかがないのでいい感じの実装ができた。

記憶がない、というのは無理なんだけど、ランダムアクセスなメモリ (画像とか) には貯めない。シフトレジスタとか FIFO が基本。

こうするとすごく電力が減ると思うんですが、どれくらい効くかわかってますか？ (奥山先生)
まだいろいろなものが一桁くらいいけると思うので、これからやろうと思います。

[ An Approach for Downscaling Images for Real-time Pattern Detection ]

VGA 以上で実時間処理。100MHz で 10 clk / pixel くらいが目標。
さまざまなサイズのパターンを検出しなければならない。
テンプレートをサイズをかえて用意する? 拡大縮小する? 後者にしました。

テンプレートの縮小は平均画素法。n/m 倍に縮小する時に、n 倍に拡大してから各画素の平均をとりながら 1/m する。計算量は大きいが劣化は少なくて済む。

外部メモリをひとつ使用。
XY 別々に拡大縮小できるので、ななめに撮影されたものにも (ある程度) 対応できる。
縮小回路は 2084 slices! (パターン検出回路はまだない)
いいね。

毎回テンプレートを大きくしたり小さくするのはなんで？ (柴田先生)
システム全体を小さくしたいので。

回転は？　(柴田先生)
パターンを回転させると、w x w のパターンについて w^3 あるので、ちょっと大変だなー、と思っている。なんとかしたい。

[ How fast is an FPGA in image processing ? ]

FPGA と最新のマイクロプロセッサの性能比較。
フィルタ・ステレオビジョン・K-means clustering. どれも演算量は多いがわりと簡単で HW 化が有効。でも、SSE3 で
128bit に対する SIMD も毎クロックできるようになった。

FPGA による速度向上率は残念ながら 5-15 倍程度で、マイクロプロセッサでも 30fps の処理ができるようになっている。
電力とかの評価は今後。
ただしFPGA 側はボードが古くて、メモリとかがあれなので、もうちょっとなんとかなるかも。メモリの性能は重要。

プロセッサと FPGA のプロセス・チップサイズを揃えたりして評価するのが重要かも (渡辺先生)
でもそういうデータは手に入らないので、気軽に買える程度、というところで揃えている。

Core2 じゃなくてグラフィックプロセッサを使ったりすると厳しいですか。DSP とか (安永先生)
GPU はクセがあるのでどうだか (乗るか乗らないかもあるし) わからないが、負ける問題は負けるかもしれない。
DSP も... Core2 がこんなに速いとは思いませんでした。

CPU のほうの開発も SSE なんかが入って大変だと思いますが、開発時間はどうですか
両方ともけっこう大変。個人差もあると思うが。

[ An implementation of a watershed algorithm based on connected components on FPGA ]

丸山先生連続でご登壇。

もともと降水の様子をシミュレーションするアルゴリズム。画像処理にも使える (というか画像処理に使う)。
外部メモリの使い方が肝。

ソフトに比べるとどうなんすか? (ふんがさん)
まったく SIMD とか使わないのに比べると x50 とか。SSE とか使われると怖いなー。

[ 複数FPGAを有するシステムでのOS機能の試作と評価 ]

SW/HW 協調処理システムで、マルチユーザで FPGA を使うようなシステム。

HW task 間での通信をサポートするような機能はある？
ありません。

いっぱいタスクがある時の context switching は？
ないので、使っている SW task が終わるまで待つしかないです。

[ 動的再構成可能ハードウェアのコンテキスト仮想化手法 ]

DRP なんかでも、コンテキストの数には限りがある。
コンテキストの遷移シーケンスをプロファイルして、統計情報をコンテキストグループの生成に使用する。分岐予測みたいな感じ。同時に入れるコンテキストをどうセットにするかで、コンテキストを外部メモリとの間で詰め替え直す回数が変わる。
遷移プロファイルがデータに依存しないようなアプリケーションでは静的にやれる。大きく変わるような場合は動的な判断が必要なので、ちょっと考えないといけない（＝次の発表)。

prefetch はしていないの? 評価は LRU と比べているが、理想はどんなものかしら (佐藤さん＠日立)
prefetch は、まだしてません。LRU とプロファイルを組み合わせるような方法を考えたい。

制約コンテキスト数、というのはグループの大きさ? 大きいほうがいいの? (ふんがさん)
やたら大きくすると余計なものがグループに入ってしまうので、必ずしもそうとは限らなくて、大きくすると逆に遅くなることがある。LRU だとそういうことはないけれど。

[ 動的再構成可能ハードウェアのコンテキスト仮想実行支援機構 ]

コンテキスト番号の論理物理変換を導入。全体のクリティカルパスがながくなってクロックが遅くなる (変換のところをパイプラインにすると、切り替えにかかるサイクル数が増えちゃうからダメなのか、やっぱり)。
それは悲しいので、コンテキスト内多状態のように変換テーブルを使わないローカル制御部もつけた階層化バージョンも用意。
コンテキスト間遷移確率 (P) を下げる努力は合成の時にしなければならない。たとえば、ループを回るたびにスイッチしたりすると、それは大変。
JPEG decoder: P=0.3~0.5
Turbo / Viterbi decoder: P <= 0.0003
結構違うんだな。

所用サイクル数をはかると、仮想化だけより階層化をいれたほうが多いのだが、クロック周波数を考慮すると階層化したほうがよい。階層化まで入れた場合、仮想化なしとほとんど同じ実行時間になり、オーバーヘッドを抑えられる。

分岐予測やプリロードはこれから。

viterbi や turbo はだいたいひとつのコンテキストに入るからPが低いの？ (ふ)
はい。だいたいコンテキスト内多状態で回ってます。

分岐がいっぱいあるようなものだと、コンテキスト内でがんばる、ということができないので、P は悪化する。

[ FPGAを用いた生化学シミュレータにおける入力ポート制約を考慮した演算パイプラインスケジューリング ]

もりりん。

スループットを上げたい、ということだけど、レイテンシを重視しているの? (梶原さん)
連立微分方程式なのでもげもげ。

レイテンシでなくて、後続ノード数でやっているのはどうなんですか?
レイテンシをクロック数でちゃんと数えてやると、自由度が下がっちゃってうまくいかないことがある。きちっと検証したわけではないが、ある程度自由度をもたせるためにこれでもいいのかも。

[ 複数のFPGAを用いた高性能流体解析システムの検討 ]

もりしー。

15桁一致でいいよ、というのはアプリケーション的に十分なの？ (谷川先生)
倍精度でいいんだけど、このモジュールだけで評価するのはまだ不十分かな

斜め方向にするのに着目したのが性能向上の決め手？ （jaist 佐藤先生)
そうですねー

[ リコンフィギャラブルプロセッサを用いた複数の拘束長に対応したビタビ復号器の設計と実装 ]

BER がどれくらいになったら拘束長をかえる、ということなら正解がわかってないといけないですよね? (泉先生)
うーん。訂正符号だから分かるのか??

送り側と受け側で拘束長の情報は共有しないといけないのでは? (柴田先生)
そういう設計になっています。

実際に使われている拘束長は? (黒田先生)
3から7くらいかが使われているんだけど、6以上はコンテキストに入りきらなかった。

全部パイプライン展開してる? ループくるくる? (泉先生)
いまのところ全部空間展開してます。

これ以上拘束長をのばしたりするとループになるが、損益分岐点みたいなのはかわる?
わかりません、、、

木金と会津大に行くのだが、木曜は午後からなので、新潟からチャリで行こうと画策中。
燃えてきたぜぇえぇえぇええ！

眼鏡と、ノートパソコンとかのディスプレイが汚れてるかどうか、というのは、意外と人が見ているものらしい。

眼鏡汚れてると、あんまり印象よくないよな、というのは、眼鏡かけていたころにずっと気にしていたのだけれど、今日研究室に遊びにきた学生が「○○さんのディスプレイすごく汚れてるー！！！！」といっているのをみて、そうだよな、と思った。

どちらも、汚れていると知らないうちにストレスがたまるものだしね。
気をつけよう。

アメリカいってきたのだが、行った先 (Pasadena, CA) は Bike week だった。
そういえば、5/15 は Bike to Work day なんだな。

自転車乗りたいなあ...

TOJ は行く気満々だったのだが、天気が悪そうでキャンセルすることになりそう。
残念。

デュポンがセルロースから燃料をつくるベンチャーを立ち上げ、だって。

デンプンから燃料を作るのはつまり酒であり、長年にわたる人類の英知の蓄積が使えるわけだ。しかし、その分人間が食べる分が減るわけであり、世界の人口が急増しているのに穀物生産量は増えてない、という現状において非常に好ましくない。

セルロース、つまり藁なんかはいままで、せいぜい藁葺き屋根や麦わら帽子に使うくらいであんまり役に立ってきてないので、これは歓迎すべき動きだ。しかし、そうとう難しいんだけどね。
日本の微生物学の人たちも頑張らなあかんのです。

今回のアメリカ滞在はなんだか忙しくて、テレビを見るヒマもなかったのだが、最後の夜になんとなく CNN をみてる。

たまには政治の話でもしようか。

こっちの大学の人と、今回の大統領選はいつもと全然違うよね、と話をしたのだけれど、アメリカは大きな変革の時を迎えているのかもしれないね。国民の関心が、日本より高い気がする。大統領制、という仕組みのせいなのかもしれないけど、日本とはみんなの政治に対する関与の意識が全然違うように思う。きょうびのアメリカ政府には言いたいことがないわけではないが、日本やドイツに民主主義を教えてくれた古き良きアメリカの魂はまだ死んでいないんだな、と感じた。

日本人は変われるか。
正直、俺らの国はこのままじゃだいぶやばいぜ。

いわゆる Sony Timer が怖いので、普段は Sony 製品をあんまり買わない (特に可動部分があるもの...) のだけれど、ヘッドフォンとかはやっぱり Sony ってすごいなー、と思う。スピーカーとかヘッドフォンとかは、けっこう Sony のを持ってるな。

で、最近買ったのは MDR-NC500D というノイズキャンセリングヘッドフォン。前に使っていた MDR-NC50 なんかと比べると、ちいさくて頼りない感じの外観だが、信号処理部がデジタル化されており、性能は全然違う。ノイズ低減効果はものすごくて、飛行機ではきわめて快適。しかも、音質はかなりのものだ。

MDR-NC50 はいかにも、「頑張ってノイズ低減しているので、ちょっと音も悪くなりますごめんなさい」的な感じ。スイッチを入れたときの感覚は、水に潜ったような感じだ。おそらくアナログ処理だと調整がシビアで、最初に買ったときは数日でハウリングがひどくなって交換してもらった。MDR-NC500D は、ノイズ低減の感じも、音楽の聞こえ方もすごく自然。ドアとか窓を閉めたような感じで、でも、人の声とかはちゃんと聞こえるので、機内のアナウンスなんかは聞き漏らすこともなくていい感じだ。

問題は、
- あんまり電池がもたない (内蔵で15時間、外付け単3x2で10時間)
- 電池が切れると何もきこえなくなる
- 軽いけど、ハンガーなんかの強度がちょっと頼りないかも。ヨドバシの展示品はぽっきり折れてた...
といったところ。でも、いいところのほうがはるかに多いね。大事に使おう。

Xilinx ISE 10.1 works pretty well on my OpenSuSE 10.3/x86_64 on Intel's Core2Quad processor. However, I couldn't compile the included Platform Cable USB driver, so I couldn't program my FPGA cards. There's a possible solution (with a non-proprietary driver) on a wiki page in University of Heiderberg, but it was a little bit old and written in German.

Here's my solution with the non-proprietary driver (the master site of the driver is written in English! I didn't know...) I took yesterday:

[ Step 1: Things to be installed by YaST ]

- libusb-devel (a library to handle USB devices)
- fxload (something to load firmware on some USB devices, including the Xilinx cable)

[ Step 2: get driver stuff ]

- Checkout the driver by: wget 'http://git.zerfleddert.de/cgi-bin/gitweb.cgi/usb-driver?a=snapshot;h=HEAD'
- Official documentation at http://www.rmdir.de/~michael/xilinx/.

[ Step 3: setup udev ]

- Confirm that Platform Cable USB's firmware exists at: YOUR_ISE_HOME/bin/lin64/xusbdfwu.hex (it must be, if you have a valid ISE installation)
- Edit /etc/udev/rules.d/xusbdfwu.rules. You may want to write /usr/share/xusbdfwu.hex to ISE_HOME/bin/lin64/xusbdfwu.hex.
SYSFS{idVendor}=="03fd", SYSFS{idProduct}=="0008", NAME="windrvr6"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",SYSFS{idProduct}=="0007", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",SYSFS{idProduct}=="0009", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",SYSFS{idProduct}=="000b", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",SYSFS{idProduct}=="000d", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd",SYSFS{idProduct}=="000f", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE"
ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03fd", MODE="666"
- Restart udev, or reboot the Linux box to load the firmware. Once the firmware is loaded successfully, the status LED of the cable will light.

[ Step 3: build the driver ]

- Extract the driver you got from gitweb in step 2.
- just do: cd usb-driver; make lib, and you'll get libusb-driver.so. This library emulates the driver (I don't know how, but this is really great...). If you're running 32bit Linux, you may have to run "make lib32" instead, but I'm not sure.
- Copy libusb-driver.so to anywhere you like.

[ Step 4: hack iMPACT to use the driver ]

- cd to YOUR_ISE_HOME/bin/lin64
- mv _impact _impact.bin
- vi _impact
#!/bin/sh
LD_PRELOAD=/YOUR_PATH/TO/LIBUSB_DRIVER_DOT_SO/libusb-driver.so $0.bin $*
- chmod a+x _impact

And try to launch "impact". Then you'll get connected!

[ Appendix: problems currently I have ]

- iMPACT fails to detect the cable when iMPACT is launched from ISE.
- Once iMPACT have failed to connect, I have to reboot my Linux box :(

Since Windows API (and MinGW) doesn't have fork() / exec() calls, I love GLib's g_spawn_sync() and its friends to spawn child process in portable (and Unix like) way.

However, GLib provides nothing like kill() to terminate processes. So I have to find a way to kill a process by myself. As a portable process identifier, g_spawn_sync() gives GPid. This is defined in GLIB_PREFIX/lib/glib-2.0/include/glibconfig.h as:
- Unix: typedef int GPid;
- Win32: typedef void * GPid;

The one for Unix is equal to pid, and the one for Win32 is equal to HANDLE (defined in winnt.h, as "typedef void *HANDLE;").
So, a process launched by g_spawn_sync() may be killed by:
kill(GPid p, 15);
TerminateProcess(GPid p, UINT return_code);
MSDN document says "The state of global data maintained by dynamic-link libraries (DLLs) may be compromised if TerminateProcess is used rather than ExitProcess."

Source code of a Gimp plugin gives a good example, but I haven't tested it yet. Hope this works...

家の iMac G5 (Leopard) だけ、.Mac で何度同期しても Safari の bookmarks が古いままで更新されず、なんでかなー、と思っていた。

ふと思い立って、bookmarks を全部削除したらあらふしぎ、.Mac な bookmarks が現れました。
なんでー!?!?!?

まあ、ちゃんとみられるようになったから、いいのだ。

4月号のサイクルスポーツをやっと読んでいる。
アメリカのフレームビルダーのコメントに、「なんでスチールバイクが流行ってるかって？プラスチックの自転車に飽きちまったんだろ」というのがあった。なるほどね。

昔は僕もカーボンの自転車ほしいなー、と思ったこともあったんだけど、やっぱりスチールフレームだろ、と思う今日この頃。

Linux な開発環境は OpenSuSE 10.3 を使っており、Xilinx ISE はどうやら動きそうなのだが、Platform Cable USB のドライバがコンパイルできない。こまった。

http://stefan.endrullis.de/en/xilinx_ise_8.2_ubuntu.html の記事によると、non-proprietary なドライバが https://wiki.kip.uni-heidelberg.de/KIPwiki/index.php/EDV:Xilinx-USB-Treiber にあるらしい。しかしね、ドイツ語なんだよ。辞書引っ張り出してきて読むかなー。

連休にじっとしているのもアレなので、江ノ島いってシラス食べてきた。
激うま。生シラスは売り切れていたので、昆布じゃこ買った。

お店で食べた丼はこんなの。これで 1800 円！

勝手に Wireless LAN の電波を飛ばすと怒られます。
11b と違う帯域の、11g とかならいいのかな...

勝手に停めたら、罰があたりそうです。

去年のツールのドーピングスキャンダル以来、散々な目に遭わされているアスタナ。

でも、勝った！いいね。
がんばれー

McEwen も不調から抜け出した模様。

もうすぐ Giro がやってくる。夏だなー。

うひー、仕事が山積みです。今日は大学にはいかないけど。
明日は行くんだろうな...

I have installed binutils-2.17 for i386-pc-mingw32 on my MacBook and iMac, and now going to try x86_64-pc-mingw32 (MinGW-W64). However, binutils-2.17 doesn't support x86_64-pc-mingw32.

So I tried to build binutils-2.18. But... failed. While building target "bfd", make fails because "makeinfo is missing."
I have makeinfo-4.11 in /opt/local/bin. Why?

The reason was that makeinfo-4.11 is too new to binuitls. MacOS X has makeinfo-4.8 in /usr/bin, so I changed my PATH, and gave priority to /usr/bin/makeinfo. Then I've done with:

% ../binutils-2.18/configure --prefix=/Users/yasu/mingw64 --target=x86_64-pc-mingw32 --with-build-time-tools=/opt/local/bin
% make
% make check

Crosscompiling Boost C++ library with MinGW libraries (on MacOS X): updated.

I have:
- MinGW toolkit (gcc and binutils) and libraries in /Users/yasu/mingw/
- GTK and related libraries including ZLIB and BZ2LIB in /Users/yasu/mingw/GTK/
- bjam for MacOS X, installed by MacPorts

I need:
- boost-regex
- boost-iostreams
- boost-filesystem

And here's how I got them:
% cd boost_1_35_0
% vi tools/build/v2
using gcc : 4.2 : i386-pc-mingw32-g++-4.2.1 : <compileflags>-I/Users/yasu/mingw/GTK/include <linkflags>-L/Users/yasu/mingw/GTK/lib ;
% bjam -sTOOLS=gcc -sGXX=g++ --with-regex --with-filesystem --with-iostreams install --prefix=/Users/yasu/mingw --build-type=complete

Mmm, bjam syntax is something cool, but difficult for me...

And just one more thing, we need to run runlib prior to use the libraries. For example:
% i386-pc-mingw32-ranlib libboost_regex-mgw42.a