カテゴリー: Conference Logs

[ FPGA Implementation of a Data-Driven Stochastic Biochemical Simulator with the Next Reaction Method ]
ほかのネットワークの形は検討した？
– これが一番シンプルだから
[ GENDIV – A Hardware Algorithm for Intron and Exon String Detection in DNA Chains ]
DP 使ってる。むうー。どうだろな。ちゃんと読んだらおもしろいのかな。
[ Virtualization on the Tartan Reconfigurable Architecture ]
WASMII だ! (違うけど)
つまりまあ、仮想ハードウェアです。
prefetch とかするのかー。かっこいいな。

[ Ringing High-Performance Reconfigurable Computing to Exact Computations ]
floating-point の、fixed-precision な計算ではなくて、arbitrary-precision な計算 (1995 年くらいに発明された仕掛けで、わりと新しい)。Exact な計算ではあるが、遅いのと、ハードウェアサポートが存在していないことが問題。
dynamic (non-linear) pipeline, short pipeline for lower latency.
構成がおもしろそうだ。
[ Applying Out-of-Core QR Decomposition Algorithms on FPGA-Based Systems ]
OOCQR algorithm.
行列ものは苦手です。すいません。
[ Multi-processor System-level Synthesis for Multiple Applications on Platform FPGA ]
XML で DFG を描いて設計するみたい。
http://www.es.ele.tue.nl/~akash/mamps/ に、サンプルとかもある。
[ A Hardware Algorithm for the Minimum p-Quasi Clique Cover Problem ]
会津大の渡辺先生。
Gene expression profile. クリークを求めるのにニューロンを使います。Matsuda’s algorithm でHopfield NN. リングネットワーク。
[ High Speed Tablation System using an FPGA designed for Distribution Tables of Frequent DNA Subsequences ]
筑波大 + 理研 GSC のひとたち。
ncRNA を検出したい。短い部分配列の出現頻度を調べる。
24bp query on 4Gbp DNA sequence.
[ Discrete Event Simulation of Molecular Dynamics with Configurable Logic ]
Boston Univ のチーム。
DMD: Descrete MD = 「なにも起きないときは何もしない」MD なので、超速い。

[ Design Space Exploration of the European Option Benchmark Using HyperStreams ]
金融のモデルは Monte-Carlo.
accuracy/acceleration design curve とか描いてる。トレードオフが選べるんだぜ。
HyperStreams っていうのを使っている。C++ っぽい何か。Celoxica の？
[ Accelerating a Medical 3D Brain MRI Analysis Algorithm using a High-Performance Reconfigurable Computer ]
Int’l Consourtium for Brain Mapping (ICBM) というのがあって、それがテストデータ (名前がすごいな)。計算速度向上は約10倍、トータルでの速度向上は約 3.6 倍。ソフトウェアでは倍精度だが、FPGA では単精度でやっている。結果が違う voxel がいくつかあるのだが、計算精度の問題というより、計算アルゴリズムが若干違っているためらしい。
Platform は RASC RC100 で、Mitrion-C で書いている。
[ Soft-Hard 3D FD-TD Solver for Non Destructive Evaluation ]
FD-TD 法は PDE を解くためのやつ。
でも integer arithmetic だから参考にはならないかなー。

Every object that biology studies is a system of systems. (Frabcius Jacob: 1974)
To understand just on life, you have to swallow the world (someone, 1981)
[ Genome-scale metabolic model of Mycobacterium tuberculosis: what does the TB bacillus eat? ]
治癒には6ヶ月かかる。slow growth mechanism をぶっ壊したい。
急速に発症するのはほとんどが子供への感染の場合。
5-10% がすぐ発症し、90-95% が潜伏。
4 drugs for 6 months to kill TB. でもいろいろ殺しちゃう。
副作用を回避するためにはもっと短期間で済む薬剤が必要。
chemostat を使って、in vivo で TB をいくつかの状態で定常状態に持っていき、transcriptome などをとる。
FBA でモデルを立ててる→mutation の結果を予測するのにも使えるぜー。
しかし、pathway がいろいろわからなかったりとか、いろんな問題がある…
どの遺伝子が essential かを in vitro で検証
TP 146 FP 87 TN 399 FN 85. けっこういい感じだ。
glycerol の供給を減らしてやると、倍増にかかる時間が19時間から69時間に。
TB をはじめとして、多くの抗原が宿主内で長生きするために Isocitrate lyase を必要とする。こいつを knockout してやると、slow growth できなくなることを実験で確認した。
GSMN-TB web server (Genome Biol. 2007, 8(5):R89)
future work: host metabolism を入れてやる必要あり (macrophage とか)
[ In vivo robustness analysis of cell division cycle in yeast with genetic Tug-Of-War method ]
もりやさん @ JST PRESTO / Cancer institute
– what’s gTOW ?
– ongoing projects with gTOW
KO (knockout) = reduce gene expression level to 0
KD (knockdown) = reduce to unknown level
OP (overexpression by promoter swapping) = increase to unknown level
gTOW = increase to some regulated level
target gene を入れたプラスミドを作って、ずがーっと増やすんだけど、コピー数を制御するために bias がかけられるような設計にしておく。コピー数の制御ができることは GFP を使って確認してる。
出芽酵母では計算機モデルより、実際の細胞のほうが robust だった！
分裂酵母ではわりと同じ感じ。
他の微生物には適用できる？
→ i’m planning to apply on E.coli
[ The interplay between gene regulatory and metabolic reaction networks in streptomyces ]
環境による phenotypic switching
analysis of microarray data in the context of constraint based models of genome scale metabolic reaction networks.

寝坊しました。まあ、最初の発表は身内なので許しておくれ。
[ PE 直結型動的リコンフィギャラブルプロセッサ MuCCRA-D の提案]
MuCCRA-1 の結合網は island style.
結合網は重要なファクタなので、直結型も作ってみることにした。
Nearest neighbor mesh ではあまりに柔軟性が低いので、ふつうはちょっと遠くへ行く線とかも引いておくが、いずれにしても直結。
IMEC の ADRES とか、日立の FE-GA は直結型。配線領域の面積コストや、隣接 PE 間の転送コストは安くなるが、データ移動の柔軟性が低い。
Nearest neighbor だけではなく、ひとつ飛ばしの配線もはいっている。
配線がレジスタなので、載ってしまえば 166MHz とか出て速い！
並列計算機に似ていて、メモリにどうやってデータをマッピングするかで大きく性能が変わったりする? (井口先生)
→ そう。MuCCRA-1 では、競合さえ起きなければ問題ないが、MuCCRA-D ではどこに置くかが大きな問題になってしまう。
プログラミングは手動? つまり、手作業で並列化プログラミングしているようなもの?
→ 配線も含めて手動です。MuCCRA Editor で配線。
デッドロックしませんか (堀口先生)
→ turn model を使って、禁止ターンをする場合とか、下方向への転送をする場合にはレジスタを通さないといけなくなる。
MuCCRA-D も大きくなったら、レジスタを増やしてやれば VC が作れる？
→ そういうことも考えてます。
我々のと近い気がするんだけど、必要な計算結果が違うところで生成されちゃって困る、ということはないか。(弘中先生)
→ あると思います。コンパイラをまだ作ってないからアレですが。
アーキテクチャ的な対策は?
→ ひとつ飛ばしの配線が意外と効くんじゃないかなー。ダメなときはコンテキストを切り替えるとか…
電力的には? (梶原さん)
→ MuCCRA-D のほうが食う。同じ問題をとくのにかかるエネルギも、全 PE がフルスピードで動いちゃってるので、いまのところ -D がだいぶ不利。
[動的再構成可能プロセッサ Vulcan2 とそのソフトウェア開発環境 ISAcc に関する研究]
ASIP: application specific instruction-set processor を、動的再構成可能にする。
32bit RISC core に RDP (reconfigurable datapath) がついた構成。
ISAcc は C プログラムから、普通のコンパイルとあわせて命令セットの合成を行う。
64PE から 128PE になると急に効くのはなんで? 比較的小さいデータパスを使いそうだから、64 くらいあれば幸せになれそうなんだけど (梶原さん)
→ ISAcc が Vulcan-1 (128PEs) 用のコンパイラなので、他の configuration ではいまいちかも
命令ライブラリとパターンマッチングしてコードを作る、というところで、ライブラリが 128PE 用になってる感じ?
→ そうですね。ライブラリが充実すれば。
カスタム命令と通常命令の EXE ステージは並列実行できない?
→ いまのところそうなっているが、それも検討中。
Configuration data のロードは multicontext で、PE が持っているのか、それとも毎回配られるのか (ふんがさん)
→ まだ決まってません。Vulcan-1 では前者で、メモリが大きくなってしまったので、後者にしようと思ったが、遅延が隠蔽できなくなってしまった。
ALU じゃなくて LUT なのは?
→ ALU based なやつも検討に入ってます
[高速並列画像処理用再構成可能プロセッサエレメントの提案]
3D モデルを使った画像認識。いい環境条件ではそれなりにできるようになってきたが、条件に対してロバストではない。そこで、3D モデルをいろいろな条件でレンダリングしたものを大量につくって、それと 2D 画像を照合する方法を考える。レンダリングを高速かつ大量に行えば、うまくいきそう?

[ 通信状態に基づくパケット毎自己再構成を用いた動的再構成プロセッサ搭載クエリトランザクション高速化装置]
日立中研の磯部さん。
データベースなどのネットワークアプリケーションで、クライアントとサーバの間 (ルータの中とか) に置いて高速化を実現するような appliance。たとえば、キャッシュをしたりとか、データベースへの挿入要求をいくつかまとめてからサーバに送ったりするようだ。さまざまなサービスに対応できる柔軟性と同時に、ルータなどに内蔵するために小型省電力であることが求められる。
通信データをメモリにバッファすると、ネットワークコントローラとプロセッサが同時にそこにアクセスするので帯域幅がもったいない → プロセッサに直結したい。
すべてのパケットがすべてのプロセッサを通過するのではなく、たとえば簡単なパケットは最初のプロセッサだけで (浅いパイプラインで) 処理を行い、複雑な処理が必要なものは複数のチップを使って処理能力を稼ぐ。
通信相手ごとに、いまなんの処理を要求されているかを把握しておき、どの回路を使うかを切り替える。構成情報は on-chip のキャッシュにあったり、外部の DRAM に置いてあったり。
TCP とかそのうえの HTTP とか SQL query を実装してみた。DDoS 対策にもなって、しかも本当に速くなるんだぜ！
チップは DAP/DNA-2 らしい。
キャッシュが当たれば 1 クロックで再構成、外れれば 10k clks. そのへんはどうなんでしょう? (泉先生)
当たり続ければ wire rate で処理できるが、外れはじめるとがくっと性能が落ちてしまう。入り口で順番を並べ替えてやればいいかもしれないが、それはそれで大変。
これ、サーバ系とはいえ、ストリーミングなので、データベース自体をやろうとしたら大変? (泉先生)
それはとても大変だと思う。
RISC core が載っているが、それは使ってない? (柴田先生)
使っていません。メモリの競合もあるので、使った方がいいか悪いか…
入力バッファを見て投機的にキャッシュに入れていくのはどう? (NEC 梶原さん)
そうですね。やりたいです。
[レーベンシュタイン距離を用いたテンプレートマッチングアルゴリズムのFPGA実装]
ふんが研の清水くん。
いま実装されているやりかたでは位置ずれに弱いので、レーベンシュタイン距離 (つまり edit distance) を導入。これは挿入・削除を許すので、位置ずれを許容することができるが、計算がしんどいので、ハードウェアで頑張って高速化する。
HSV に変換して色を検出。なるほどー。
色の境界線を 0度、45度、90度、135度の4種類の接線に近似して、この4つにそれぞれ文字を割り当てることで、画像を文字列化する (how cool!)。
Bach-C で書いた。Handel-C と違って、タイミングの制御はコンパイラがやってくれる。まじかよ。
水平・垂直の距離計算は並列にやる。で、そのセットを4つ並べて x8 。
FPGA で、2.8GHz Xeon の 4.8 倍くらい。
DP のテーブルはメモリに全部持ってしまっている? (おさな)
32×32 だからまあいいか、ということで入れてしまっている。
標識が回転しちゃっていることとか、文字の大きさがどうかとかあると思いますが (泉先生)
大きさに関してはある程度 tolerant であることを確認した。回転はこれから検証。
赤・青の検出のエラーレートはどれくらい? テンプレートの数は? (廣田先生? @ 九大)
色の識別は自分の実装でないのでノーコメントです。
いまは大分類の (赤い丸とか青い四角とか三角とか) しかないので、たいした数ではない。大分類したあとで小分類のを作っていかなければならない。評価にレーベンシュタイン距離を使っているので、計算量はテンプレートの数にリニアに比例するだけで済む。
[生化学シミュレータReCSiPにおける反応速度式共有化]
山田さん。
スライドがかっこいいぜ兄貴。
Solver Core は共有化しても 100MHz を確実に越えられる感じ。単体のときよりは若干複雑になるので、まあ、数 % は落ちるが。スライス数はだいたい 35% くらい減る。わお。
スループットが 14% くらい落ちてる。これはパイプラインピッチが長い方に揃ってしまうのが問題で、やっぱり入出力のところをなんとかしないといけないな。
グラフの同型判定はとても大変 (NP) だけど? (飯田先生)
まだ小さいので、exact に最適解が求まっている。
ずっと演算器が忙しい、というのが前提だと思うんですが、暇なのもあるんですか? (森先生)
システムがいろいろな式を含んでいるので、multifunction なモジュールを作ってやらないと面積が無駄になってしまう。
連立する式のセットを眺めたときに算数のレベルで簡単にできることとかありそうだよね (森先生)
ええと・・・方法があったら教えてください → 私もわかりません(笑)。reconfiguration と、共通部分式の抽出を組み合わせたりすると面白くなりそうですね。
木のマッチングはNPじゃなかったかも。でも、加算みたいな、左右が可換な演算はどう? (泉先生)
まだ考えていません。とてもむずかしい。
稼働率で評価しないといけないのでは? (飯田先生)
それはいまやってます… 半年くらいお待ちください m(__)m
[リコンフィギャラブルマシン SRC-6 を用いた海洋モデルシミュレーションの実装方法]
POP: Parallel Ocean Program
3次元球体上で流体基礎方程式を解く、気象予測とかの標準。
けっこう速いのだが、DMA が時間を食ってしまって Xeon に負ける場合がある。配列をうまく切り出したり、ブロックサイズを適切に選ぶことで FPGA が有利になる。
精度は single? double? (井口先生 @ jaist)
double です。64bit です。
わお。
ソフトウェアでも、ブロックサイズでずいぶん違うんだけど、やっていることは同じ? DMA の速度はどれくらい出ている? (井口先生)
演算量も workset サイズも一緒なんだけど、グラフに出ているのは関数1回あたりの時間なので。
DMA について、図 9 で送っているデータは 256KB で、300us だから 1GB/sec くらい。バンド幅としては悪くないですね。
いろいろ改良しても、やっぱり DMA が律速だと思うんですが (泉先生)
メモリインタリーブをするとコンパイラが別の配列として認識しちゃう。
オンボードメモリにデータをどう配置するかが問題ですだ。
[チップ間無線通信を用いた3次元動的リコンフィギャラブルデバイス MuCCRA-Cubeの提案]
天野研の斉藤君。無線方式 (誘導結合なのでベースバンド信号だ) での積層チップ。
MuCCRA-1 がベース。MuCCRA-1 は、PE 間結合網が island style.
RoMultiC 入ってます.
チップを重ねるときに、同じ向きで重ねるのでなくて、違う向きで重ねてやると配線長を短く使うことができるのではないか!?
重ねたチップを同一コンテキスト番号で駆動するか、個別に駆動するか。後者はパイプラインみたいにして使えそうだ。
MuCCRA-Cube は各 PE がインダクタをもっており、それで双方向通信する。コンフィギュレーションデータも、一番下の段から入って、無線で転送される。そのへんの面積オーバーヘッドは 10% くらいで済む。
でも、評価してみたら、あんまり配線長に効いてこないので、全部の PE にインダクタをもつ必要はないかも。
3次元方向に飛ばす場合に、どこまで飛ばす? 気合い入れすぎると相互に干渉したりしない? (泉先生)
基本的に隣接する、上下のプレーンに飛ばすことしか考えていない。
縦方向のほうが通信コストが高くなるから、同一コンテキストで動かすような密な関係じゃないほうがいいかもしれませんね (泉先生)
Multicore な感じとして捉えれば、同一平面の遠くの別のコアよりも、上下のプレーンの別のコアのほうが近い。
誘導の漏れを使って、隣と通信するようなことは考えてない? インダクタを switch matrix ではなく PE に持たせたのはなにか理由が? (森先生)
PE 間で接続したほうが、アプリケーションの実装が簡単になりそう。
電力削減って、どこのが減りそう? (堀口先生)
配線の電力が減りそうです。
インダクタによる通信のレイテンシは? (名古屋先生)
1GHz で通信して 1クロック = 1ns とかで OK.
[動的再構成型ハードウェアの階層型状態切り替え方式]
堀口先生。
PE 使用率がだいたい一定になるようにうまく均してやると消費電力が安定したり、削減できたりするのではないか、というのが motivation. 電力モデルを作ったり。
いろいろ調べていくと、idle な PE が意外と電力を食っていた! DRP はタイル単位でしか止められないので、状態遷移を細かい粒度でやるなら階層的な状態制御コントローラが必要で、もちろんそのぶんハードウェアコストが高くなるけど、いい感じだ。動作電圧なんかも制御できるようにするとより効果的、というか、リーク電流の割合が増えれば増えるほど、それは必須の処理になる。
いまの構成だと、PE を全部使えるほど配線がないので、このまま PE を増やすよりも、配線可能性を高めたりするほうが電力的にはよくなる? (柴田さん)
64PE 単位だとやっぱり粗すぎるかもね。
再構成をしないほうが電力効率がいい、という結果が出てましたよね (弘中先生)
メモリとのデータ転送なんかもあるので、プローブを当てて測っているわけではなくて、DRP compiler が出しているのでなんとも。しかし、コンテキストをまとめた場合にどうなるか、という実験 (もちろん推測なわけだが) の結果からパラメータを導出することができなかった。
DRP は複雑だが、もっと簡単なモデルで再構成したほうが電力的に得だ、ということはあるんでしょうか? (弘中先生)
そうなるといいな、と思っていたんですが、うまくいかなかった。
速度最適、とか、電力最低、というのはあるのだが、1W あたりどのくらい、という効率の計算にしようとしたら、難しい。
[粒度可変構造論理セル向け算術演算回路の実現]
佐藤さん @ 熊本大
Hybrid cell: FA + 4bit FF = 2-LUT.
これに front logic というのをつけて、Add/sub, 2-LUT, 2-MUX として使えるようになっている。さらに、制御信号線を入力として、3-NAND, 3-AND, 3-EXOR ができる (3-OR, 3-XOR はダメ)。4 入力もできるけど、3 入力より poor.
で、これを使った各種の算術演算器を作成。
Carry Select Adder とか Parallel Prefix Adder とかも作っててかっこいい。
logic だけで interconnect が入っていないけど、アレイ型でtree いれたらやばいとか、なにか考えていることはありますか? (泉先生)
→キャリーチェーンをなるべく使いたい。
結局 RCA がよかったりする、と思うんだけど、Wallace はどう?
→キャリーチェーンはうまく使えなかった…
粒度固定の、一般的なロジックセルの場合と違う結果になったりしました (柴田先生)
→Carry Lookahead はうまくいかなかった。
最近は embedded multiplier がはやりですが
→できれば均一な構成にしたい
[スモールワールドネットワーク化配線構造の詳細遅延評価]
西岡さん @ 熊本大
short から long まで、4段階の長さの配線を持つ island-style FPGA に SWN を加える。
E 本の配線 (edge) があるときに、確率 p で pE 本の SWN wire を追加。かわりに long line を削除する (プロセスが微細化するほど long line の使用率は低下)。
VPR の PathFinder アルゴリズムをベースにして配線アルゴリズムを実装。
1. すべてのネットに対してコストが最小になる配線経路を探索
2. 競合する配線にはコストを加算
3. goto 1
SWN ラインがあると、マンハッタン距離＝最短距離とは限らなくなるので、そこの変更が必要。なるほどー。
評価は、SWN 生成確率をかえて、それぞれで 5 パターンの配置を試した。MCNC benchmark.
配線に時間がかかるって、どれくらい? (井口先生 @ jaist)
→1% の場合と 2% の場合で単純に 2 倍。SWN wire の数に線形比例。
基本的に long line のかわり? p はどれくらいにするのがよさそう? (産総研の方)
→そうですね。p のほうはまだ一概には言えない感じ。
ランダムに斜め線があるのと、規則的に斜め線があるのでは、ランダムであったほうがよいという感触はある? (森先生)
→規則的にやったほうが、遅延は削減しやすいと思うが、リソースを食い過ぎる可能性があるので、ランダムのほうがいいかなー、と思っている。
→ランダム性を持ち込んだ時点であちこちで悪さが出てくるので、もしかしたら規則的にするほうが、製造プロセスや CAD の都合もあって、そっちのほうがいい、ということもあると思う。
[SoC埋め込み型プログラマブルロジックePLX向け自動配線ツールの検討]
立命館の奥野さん。
SoC にプログラマブルロジックを埋め込むことで、少量生産品にも使えるような SoC の開発を狙う。
LUT, FF, Interconnect block が交互に並んだカラム型の構成で、こいつの配置配線手法。
Dijkstra のアルゴリズムを使って、個々の net を配線する基本ルータを作って、それを繰り返すことですべての net を配線していく。なので、配線をする順番次第で性能が左右されちゃうのだが、それは今後の課題みたい。
interconnect は階層構造みたいだ。
ePLX はアーキテクチャを絞って、配線を減らしているから SoC に適している、と考えてよい? (梶原さん)
→ ルネサスさんといっしょにやっている。フィルタ用とかプロセッサは持っているので、プロセッサでも信号処理でもない、ノリスケロジック (って、glue logic みたいなものだな)。
LUT matrix はどうつながってる? (弘中先生)
→ ひとつからは 13 箇所に直接つながっている。
なんで 2-LUT? それじゃゲート一つじゃない? (飯田先生)
→ 最初は LUT ではなくて NAND + Inverter の海だった。LUT ひとつでロジックブロックなのではなくて、ぜんぶで一つの LB みたいな感じ。
そうすると LUT 間の接続の議論もありますよね? クラスタリングとか。
→ それもまた議論しています。いまの構成で OK 、という結論がでているわけではない。

[ Software Innovation in Systems Biology ]
Herbert M.Sauro.
CompuCell3D: lattice-based な 3D モデリング
What’s missing from Today’s simulation tools
– Automatic model reduction via time scale separation
– Model composition, ability to build models from small models.
– Assistance in choosing rate laws (rate law builders)
– Robust bifurcation analysis tools for large systems
– Interactive tools
[ Copasi tutorial ]
Deterministic では LSODA を使ってる (LSODA は Adams / backward differentiation formula (BDF) でできてる)。あと 4th RK.
Stochastic では NRM.
Hybrid もあるんだぜ。
MCA: elasticity = how reaction rates are changed by concentration change.
Parameter scan
[ CellDesigner ]
reaction / specie を ontology に binding するのはどう？
ときかれてました。
[ Virtual Cell ]
Parameter space を探索するのではなくて、
model space exploration はどうだろう？　とかいう discussion がでてた。
つまり、model が given でそのパラメータをスキャンするのではなくて、
reaction とかそういう、model 自体をかえながら探索するってのは
どうなのかね？と。
おもしろそうだけど。

[ 配線共有型マルチコンテキスト手法を用いた低消費電力化 ]
熊本大の門司さん(末吉lab).
コンテキスト間で配線を共有することで再構成電力の削減を狙う。
再構成エネルギはけっこう減るが、全部入れ替えちゃう場合と比べると
dynamic power が減らないのが悲しい。
まだもうちょい進めそうだな。
谷川先生:
切り替えに必要な MUX って評価に入ってるの？
– まだいれてません
[ メディア処理向け小面積リコンフィギャラブルアーキテクチャ ]
お、試作した模様。90nm.
ターゲットをしぼって構造や構成情報を小さくしている。
再構成は 32 cycles で、ふつうにアプリを作ると 300cycles ごとに再構成したりする感じ。
MPEG-2 のリアルタイム処理が可能。H.263 とか MPEG-4 もやっている。
[ ストリームアプリケーションを用いたマルチコア DRP の性能評価 ]
DRP を multicore にして、クロックを独立させたりしちゃう。なんかかっこいいな。
single core だと 8 tiles x 1 で、multicore だと 2 tiles x 4.
井口先生:
4 cores なら最大で 4 倍になれる？
– はい。3倍出てるから妥当かなーと思ってます (そうなのか？同じ面積だから速くなるってすごくね？)
もっと core を増やしたらどうなるでしょう？
– （やべえきいてなかった、ごめん）
谷川先生:
マルチプロセス構成でデータの受け渡しがどうなってるかが知りたいんですが
– （図をつかって説明してらっしゃいました）

[ AESのS-BOX回路のDPA対策設計 ]
防衛大の佐々木さん。
FPGA 上に、gate level のランダムマスク方式で構成。
(module level のマスク方式というのもある)
消費電力のピークがちゃんとなくなっている。
RSL → MRSL で回路規模があんまりへらなかったのがざんねん。
井口先生:
実際の攻撃はどんな感じで行われるの？
– 実験するときは Vcc にオシロスコープを接続して波形を観測する。実際に攻撃が行われたという報告はないので、どんな手口になるかはわからないが、原理的には可能。
[ FPGAを用いたウイルスチェックシステムの構築と評価 ]
東邦大の石田さん。
今回は update の自動化がメイン。
複数のパケットに渡った場合の処理に関してはこれから実装する予定。
(パケットって ethernet の frame なんですかね?)
NEC梶原さん:
パターン数がふえたときに容量をこえない?
– FPGA が大きくなっていけば…
マッチングは NFA とか使って並列探索とかしているの?
– 単純に全パターンをマッチングしている。新しいやりかたは産総研のほうでも研究しており、合流する予定
JTAGだから遅いの?
– SRAM にいちどバッファして一気に書き込む予定。
井口先生:
全部合成しなおしてるの? メモリのデータだけ書き換えるとかでは無理?
– いまは全部やっちゃってます。将来は partial reconfiguration もします。
[ 再構成可能な演算回路を含む hwObject によるテンプレートマッチング回路 ]
農工大の佐藤さん。
画像のテンプレートマッチング。
hwObject ってなんかすごいな。C++ で書けるのかー。
IP を組み合わせてホストと協調動作するようなのを作ってる。
永山先生:
hwObject を用いることで、いろんなテンプレートマッチングの仕掛けを意識することなく実装することができる？
– yes.
谷川先生:
hwObject は、IP を作る人がいろいろ考えて (論理回路を書ける人が) 作って、利用者はソフトウェアっぽく使う、というのであっているんでしょうか。
– 回路設計者は Verilog-HDL を書かないといけません。hwObject はライブラリ化された bitstream を呼び出す機能をもっている。
C ベース設計と違ってライブラリが必要なわけだけど、どんな違いが?
– ごめんなさい、よくわかりません。
[ 算術分解を用いた基数変換回路の構成法 (2) ]
井口先生。
(2) って!
p 進数から q 進数への変換。
LUTカスケード・算術分解(n 進→2進数)・q 進加算器を用いる。
2進化p進数: たとえば BCD
強烈におなかの具合が悪くなってきいてませんでした…
[ EVBDDを用いた数値計算回路の構成 ]
永山先生。
不等区間分割 episode 2.
EVBDD を使うことで、LUT cascade の段数も減らせるんだそうだ。
[ digit serial 演算を用いた再構成型アーキテクチャの検討 ]
bit serial とは違う (2bit 単位とか)。
DS-HIE アーキテクチャ。
インタコネクションは Benes 網。静的なルーティングのみ。

[ リアルタイム画像処理システムの構築 ]
富士ゼロックスのひとびと。
Xerox で Intel といっしょに MXP5800 というプロセッサを作った。
これからは MFP のリアルタイム画像処理能力が重要。300bpi, A4 color だと 24MB!
でも、新しいアルゴリズムをすぐ載せたいので、FPGA でなくソフトウェアで処理したい (しかも、configuration している間に何枚分もの印刷時間がロスしてしまう！)。DSP だと複数使うことになるし、ちょっとお値段が。
そこで reconfigurable processor ですよ。5 種類の PE がクラスタになっており、それが8つ載っている。300dpi, 35ppm で JPEG と高圧縮 PDF を作れる。高圧縮 PDF はテキスト部を G4 (lossless) 圧縮、画像部を JPEG 圧縮するので、処理は超重たい。
JPEG 圧縮するところは BW と color を reconfiguration で切り替えていたりする。
IPFlex 佐藤さん:
SIMD でも、数さえあればいいの?
– SIMD だとシリアル処理とか条件分岐が怖いから無理じゃないかなー
– MXP はデータパスが自由にいじれるので、SIMD っぽくもできるし、そうじゃない使い方もできる
ASIC に reconfigurable な部分を入れるというアプローチについては?
– service & solution なので、fully programmable であることを目指した
– ASIC でもうまいバランスのとりかたができるかもね
名古屋先生:
もともとこれはどういう同期で開発されたの?
– IA ではスピードが出ないような処理むきにがんばってみた、ときいている
これ、5800 を使うというのは前提だった? それとも one of options だった?
– option なんだけど、いろんな制約 (時間とか) で事実上これしかなかった感じ。
[ FPGA によるリアルタイム画像処理 ]
九州工業大の佐藤さん。
ロボット向けの画像処理。FPGA にカメラ直結だ!
とりあえず、カメラと FPGA と PC (FPGA-PC は USB) をつないでみた感じ。
画像処理部はまだできてないんだけど、動いたぜ、いえーい。
FTDI の USB-RS232C のインタフェイスなので、1MB/sec くらいしか出ないらしい。
名古屋先生:
通信は 1MBps でたりる？
– 画像処理後の結果だけ返すのでだいじょうぶ。
どんな加速処理をやる感じ？
– まだ考えてないんですすいません
FPGA の外付けの SDRAM だとそこがボトルネックになるのでは?
– メモリの周波数を上げるとかでなんとかしたいのだが… (いやだめだろ)
井口先生:
九州工業大で作ってるアレに載っているアルゴリズムってどんなの?
– 白線認識とか
そういうのを FPGA でやっていく方向なんすよね
– はい
どういう処理をするかをちゃんと考えたほうがよさそうだなぁ。
[周波数変調を用いた超音波計測のリアルタイム処理]
九州工業大の大笹さん。
ロボットシリーズ #2.
超音波センサをたくさん使うと混信するので変調するんだが、
変復調をアナログ回路でやるのを作るのが難しいので、FPGA でやってしまおう！
atan() を CORDIC でやろうかと思ったのだが、やめた。うひ。
差分方程式にしちゃうのだ。
Samsung lab. の方:
マルチパスフェージングとか起きない？
– ぐはっ
井口先生:
超音波センサはどれくらい幅をとれる？
– 中心周波数 40kHz +- 1kHz で駆動できる。
– 受信側は 40kHz – 42kHz くらいなので、中心周波数をちょっと上げればいいかな
[動的再構成可能なマルチレート対応 LDPC 符号復号器の実装]
早稲田の今井さん。
LDPC: Low density parity check = 線形誤り訂正符号。
性能はいいんだけど、実装が大変なんだ。
Samsung lab. の方:
今回用いた符号はどんなの?
– あー、すいません、予稿集に書いてあります (ちゃんと受け答えしてましたが、わしにはわかりませんでした、すいません)
名古屋先生:
Reconfigurable の意味がよくわかりませんが、動的に符号化レートをかえられる、ということ？
– はい、デバイス自体が reconfigurable なわけではありません。