月別アーカイブ: 2010年10月

TinyOS + iris mote on FreeBSD HOWTO

This is how to make our iris mote with MTS400 sensor board work with FreeBSD. Although it’s difficult to make the full feature of TinyOS toolkit (especially Java based tools on the host side) because of several limitations of the toolkit, it’s still possible to develop everything on the motes and host PC(s) with FreeBSD.
Before getting started, the user must be join dialer group to “dialer” group to control /dev/cua*.
[ Step 1: ports setup ]
Since iris motes have Atmel’s AVR processors, we need avr cross compiler to make them work. I’ve installed following softwares from FreeBSD ports collection.
– devel/avr-gcc
– devel/avr-libc (without documentation)
– devel/avr-gdb
– devel/avarice
– devel/avrdude (needs “cp /usr/local/etc/avrdude.conf /etc/avrdude/” after installation)
[ Step 2: NesCC installation ]
To compile programs run on motes, we need NesC compiler (that calls avr-gcc for iris motes). However, NesC has a small incompatibility with the latest avr-gcc comes with FreeBSD ports. Simply edit src/unparse.c and comment out line 812 and 813. Without this patch, avr-gcc will experience an “internal compiler error”, then terminates abruptly.
nesc-1.3.2/src/unparse.c
811: /* gcc wants the attributes here */
812: // prt_type_elements(CAST(type_element, d->attributes),
813: // flag_gccize ? 0 : psd_no_target_attributes);
Then just:
% ./configure –prefix=${HOME}/work/xbow/tools
% gmake
% gmake install
this will install nescc in ~/work/xbow/tools.
[ Step 3: Build TinyOS environment ]
Since I couldn’t build latest trunk (revision at r5194) for iris motes and TinyOS-2.1.1.3 doesn’t have mts400 driver, I’ve checked out trunk at revision r5166 and it builds.
% cd ~/work/xbow/
% svn checkout http://tinyos-main.googlecode.com/svn/trunk tinyos-5166 -r 5166
% ln -s tinyos-5166 tinyos
% set path = ( /usr/local/diablo-jdk1.6.0/bin ~/work/xbow/tools/bin $path )
% setenv TOSROOT ~/work/xbow/tinyos/
% setenv TOSDIR ~/work/xbow/tinyos/tos
% setenv CLASSPATH ~/work/xbow/tinyos/support/sdk/java/tinyos.jar:.
% setenv MAKERULES ~/work/xbow/tinyos/support/make/Makerules
Next, we need some patches to build TinyOS on FreeBSD before building the tools:
% cd tinyos/tools
% vi configure (change #!/bin/sh on the first line to #!/usr/local/bin/bash. That’s because FreeBSD’s Bourne shell can’t run the script…)
% vi misc/tos-locate-jre (replace “readlink -q” by “readlink”. The command doesn’t require -q option.)
% ./configure –prefix=${HOME}/work/xbow/tools
% gmake && gmake install
This will install uisp and many other programs in ~/work/xbow/tools/bin. Unfortunately I still can’t run Java based tools, I can use C based SDKs.
[ Step 4: Program the Mote NOW! ]
The first one is the “Blink” application. Assume that the programmer appears on /dev/cuaU0 (and the mote interface on /dev/cuaU1).
% cd ~/work/xbow/tinyos/apps/Blink
% gmake iris
% gmake iris reinstall mib520,/dev/cuaU0
The LEDs will blink!
Next thing is test with radio… The client ID must be specified at gmake reinstall.
Compile for client:
% cd ~/work/xbow/tinyos/apps/tutorials/BlinkToRadio
% gmake iris
Install for client 0x1234:
% gmake iris reinstall,0x1234 mib520,/dev/cuaU0
Install for client 0xabcd:
% gmake iris reinstall,0xabcd mib520,/dev/cuaU0
Set up the basestation:
% cd ~/work/xbow/tinyos/apps/tutorials/Basestation
% gmake iris
% gmake iris reinstall mib520,/dev/cuaU0
Compile C based serial forwarder:
% cd ~/work/xbow/tinyos/support/sdk/c/sf
% sh bootstrap && ./configure && gmake
% ./seriallisten /dev/cuaaU1 57600
The packets are displayed by serial forwarer:
00 ff ff ab cd 04 00 06 ab cd 00 01
00 ff ff ab cd 04 00 06 ab cd 00 02
00 ff ff ab cd 04 00 06 ab cd 00 03
00 ff ff ab cd 04 00 06 ab cd 00 04
00 ff ff ab cd 04 00 06 ab cd 00 05
00 ff ff 12 34 04 00 06 12 34 00 01
00 ff ff ab cd 04 00 06 ab cd 00 06
00 ff ff 12 34 04 00 06 12 34 00 02
00 ff ff ab cd 04 00 06 ab cd 00 07
00 ff ff 12 34 04 00 06 12 34 00 03
00 ff ff ab cd 04 00 06 ab cd 00 08
OK, cool.

RIS: 再生可能集積システム研究会 @ ひよし

[3次元積層技術を用いた乗算回路設計に関する研究]
山形大の多田先生。
3-D ベクトルプロセッサとかもある。
コア・ベクトルキャッシュ・I/O が3段重ねで、電力効率を上げられる。
もうちょっと細かい粒度の、演算器とかを作れないか?というのがこの研究の課題。
配線長が長くなってしまうかと思いきや、回路内の長い配線をうまく減らせて、総配線長が短縮し、6〜30% くらい遅延を削減できた。
回路を subblock に分割し、かつ貫通配線の数を抑えるように最適化することが重要。
先行研究としては Kogg-Stone ADder の3次元実装というのがある。
論理深度レベル分割では層を増やしても遅延の改善が見られなくなる。
ビットスライス分割は3層でも遅延が減らせる。
クリティカルパス上のゲートが多数の場合には均等な分割が困難。
TSV を経由することによりクリティカルパスが変化する可能性も。
部分積の生成・圧縮部 (booth encoder + wallace tree) をバラしてみました。
ビットスライス分割よりクリティカルパスを考慮した分割のほうが面積が増える+総配線長は長くなる。
TSV は本来遅延に悪影響を及ぼすが、遅延を改善することができた。
2次元実装と比べて最大で 27% 。
遅延には容量成分がかなり効いてくる。
TSV のサイズは縦横 1um で高さが 2um くらいのものを想定していますが、ちょっといまの技術では作るのはキビシイかも、とのこと。
[再利用可能な動的リコンフィギャラブルプロセッサの開発]
ふんがさん。
半導体は環境にやさしいか?
消費電力とか廃棄ではなくて、一番問題なのは製造時の薬品やエネルギーの使用かも。
さまざまな製品で汎用的に使えるチップがあれば、製品を廃棄するとこに取り出して転用、みたいなことができるのではないか。
だけど基本的には新しいプロセスを使った方が圧倒的にお得なので、大量生産大量消費の世界になっておるわけです。半田付けをはがしたりするのは問題だし。
しかし、いい加減プロセスの微細化も遅くなってきているし、集積度以外は改善しなくなってきているので、状況は変わるかも。
ビルディングブロック型 SoC.
製造後にいろいろ積み重ねちゃって何でも使えるようにすればいい。
誘導 (磁界) 結合ならたくさん積み重ねられるし、電源以外は半田付けが不要。
放熱とかはアレですが。
MuCCRA-Cube はプロセッサとプロセッサが 1:1 でつながるようになっている。
データ転送クロックは 1.5GHz, プロセッサクロックは 15MHz なので、プロセッサから見ると1クロックにたくさんのビットを送れる。
W 単位の消費電力の場合のワイヤレス送電はけっこう大変。
[三次元ワイヤレス接続用ルータおよびバス構造の提案]
佐々木くん@ふんが研。
容量結合は2枚までしかいけないので誘導結合です。
バブルフロー制御楽しいな。パケットがぐるぐる回って、受信先の入力バッファが空いてたら拾える。トークンリングみたい。
共有バス型の通信モジュールも積んでおり、これだと Tx がひとりで残り全員が Rx になる。各レイヤがタイムスロットごとに順番に Tx になる。
チップは12月にできる。
シミュレーションで core 200MHz, inductor 4Gbps at 40mW という結果が出ている。
バブルフロー制御はリンク使用率が uniform traffic で 90%とかまでいける。いいね。
共有バスのほうは timeslot が回ってこないと送れないのでそれほどでもない。
[省エネ世界におけるシリコンウェハ]
シリコンウェハ出荷数量・面積ともに 8inch は減っており、12in に移行。
200mm や 300mm は伸びているが 450 はどうかな… という状況。
パワーデバイスでは IGBT がモリモリ伸びている。
5年先くらいまでは IGBT はシリコン、SiC はダイオードなら使われるようになるかも。
高耐圧用だと中性子照射炉が必要。日本には・・・ 世界的には将来の供給不足が見込まれる。
地殻までだと O(49.5), Si (25.8), Al (7.56), Fe (4.70) マントルまで入れると Fe が多いけど、さすがに人間が使えるのは地殻だし、Si は枯渇しない。
シリコンウェアはどこまで効率的に使われているのか?
ウェハの出荷容器はウェハ1枚と同じくらい (1万円くらい)。リユースしてます。
300mm シリコン単結晶、引き上げ時の長さは 1.6m 〜 2.5m くらい。頭としっぽは太さが違うから使えないので、長いほどよい。
150kg のだと、使えるのは 61kg, 300kg なら 171kg (57%) が使える。
つまり、引き上げでの収率はたかだか 60% (ここでの残りの部分は純度がいいからまた使えるということかな?)
加工収率は 1.2mm から 775um にするからここで 65%。これの残りは不純物(特に砥石)の混じり具合によってセメントにしたり、あるいは太陽電池方面などへ。
さいごは 30um〜70um にするからもっと捨てている。
ウエハの内側と外側での特性の違いとかあるんだけど、300mm くらいはちょうどよいらしい。
引き上げたままだと void が入っちゃったりするので、表面だけ無欠陥にするような加工 (気相成長させたりとか、高温で anneal するとかね) が必要。内側の void は放熱とかのためにあったほうがいいときもある。
radiation tolerant とか industrial / military temp なのを作るには、ある程度ウェハの特性も関係してくる。
[状態評価を用いた多重化方式によるモジュールの長寿命設計]
過半数のモジュールが壊れても大丈夫な stateful NMR を改良して、resettable stateful NMR.
モジュールが復旧したときに、モジュールの状態評価を正常に戻すことができる。
復旧、という概念がディジタル回路とかだと実際のところどうなの? → チップを取り替えるとかそういう、モジュールレベルのことになりそう。
[旧型PCにもとづく太陽光発電によるグリッドの提案]
太陽電池 1m^2 で年間石油換算 39L, 森林面積 316m^2 に相当。
ということはガソリン 40 リットル燃やしたら 316平方メートルの森林が1年かけて吸収しなきゃいけないということですね?
実験で使ってるPCは Atom とか Celeron M なので、うーん…
でもこれ四年生がやってる研究なので、続きは本人次第かな。がんばれー