Diary/2013-9-18
デザインコンテスト・プレーヤ作成の落し穴
正確なルールは↓の通りですが，
http://lut.eee.u-ryukyu.ac.jp/dc13/rules.html
"first player"，"second player"の扱いが落し穴になっていたようで．
よく(普通に？)読むと，流れとしては，ホストの動作はこんな感じなのですが，
- ホストシステムは，接続された二つのクライアントに対して，生きてるか確認するために'0'を送ってくる
- ホストシステムは，接続された二つのクライアントに対して，"fist player"あるいは"second player"かを決める
- ホストは，"first player"には，(5,5)に何か置けというコマンドを，"second player"には，(A,A)に何か置けというコマンドを送る
- ホストは，"first player"と"second player"のどちらを先手にするか決めて，(これは'-r'オプションで決まるらしい)先手に決めた方に，3XXXXというコマンドを送る．
- "first player"と"second player"の後手に決めた方に，4XXXXYYYYというコマンドを送る．
- 以降は，ゲームがおわるまで，3XXXXというコマンドが送られる．
ここで，落し穴は，(2)のところで(A,A)を受信した時点で
「自分は"second player"だから後手」だ，と，早とちりしてしまうと，
3XXXXが送られてきたときにエラーとしてしまって変なところにおくか，
4XXXXYYYYがくるまで待ち続けてしまう，ということで無効になる，と．
デザインコンテスト
残念ながら(当然ながら？)予選落ち．
某高位合成処理で実装したところにも負けちゃったのが残念．
12月を目指してがんばれる...か？
話を聞いてると，上位のチームは，
忙しい中でもちゃんと時間を割いていらっしゃるようなので，
出るからには，もっとがんばろう．
FPGAで実装する
からには，パイプライン処理でリソース使用率を向上させることこそが
鍵なんだろうなあ，とあらためて思う，など．
リソースシェアリングの究極が(おそらく)CPUなわけで．
そういう風に実装できるように
- アプリケーションを選ぶ
- アルゴリズムを工夫する
- がんばって記述する
- あるいは，手を抜いても，その観点でちゃんとできる言語で楽して書く
とかが，大事なんだろうなあ．