SystemCにおけるオブジェクトの扱い

SystemCでは、シミュレーションの動作環境から、sc_objectを取り出す手法は、標準的に用意されている。

ところが、取り出したsc_objectをsc_signalに変換しようとすると、一筋縄ではいかない。
sc_signalがテンプレートで実現されていて、簡単に変換できないようになっている。
ダイナミックキャストを使うと変換は可能だけれど、試してだめなら他の候補を試すといった、試行錯誤となってしまう。

NSLから変換したSystemCにおいて、sc_traceに追加する信号を、シミュレーション動作環境から自動的に取ろうと、今日一日いろいろと試していた。

検討の結果、結局、シミュレーション環境から信号名を拾うことをあきらめ、NSLCOREから、モジュールの階層構造を追いかけて、明示的にsc_traceに追加することにした。
トレースの信号管理のため、-sc_trace_depthで、何階層まで信号を読み出すのかを指定できるようにした。

トレース信号だけなら、これで十分だけれど、将来へのステップとして、テストベンチから、シミュレーション環境内のオブジェクトを参照したり更新する方法を考えていたけれど、これはやはりダイナミックキャストを使わないとだめだろう。

NSLシミュレーション制御構文追加

20110503版で、シミュレーションを制御するための構文を追加した。
追加した構文は、

• _initブロック：リセット後自動的に実行される順序実行ブロック。モジュールの実行文より先に１つだけ記述可能。
  
• _delay：_initもしくはseqの順序実行ブロックないで、指定する数値の遅延を行う。
  

の２つ。
どちらも、simulation専用構文であり、declare文にsimulationの指定が必要。

例題を下記に示す。

declare tut20 simulation { }

module tut20 {
        _init {
                _delay(100);
                _finish("Hello World: time = %d",_time);
        }
}

Cygwinがインストールできない環境へのETロボコンに向けたnxtOSEK簡単インストール

私の職場がそうなのだけれど、簡単にソフトウェアをインストールさせてもらえない環境が増えている。
ETロボコンでも、（会場に持っていくことを考えると）実際にロボットにプログラムをダウンロードする部分はノートパソコンを使わざるを得ないとしても、プログラムのコンパイル程度は、計算機室などのPCを使いたい要望があるだろう。（ロボットにダウンロードするためには、最低限LEGOのデバイスドライバがないと、LiveCygwinだけでは何ともならないことに注意）

こういった要望のため、CygwinをCDROMからもしくはフォルダから、インストールなしで直接起動する仕組みをLiveCygwinとして提供してきた。

一時、nxtOSEKインストール済みのLiveCygwinも提供していたけれど、nxtOSEKがあまりに頻繁にバージョンアップしていたので、提供を中断した経緯がある。

このところ、バージョンアップも落ち着いたし、もう一度、簡単インストールパッケージを作成しておいた。

導入手順は、次の通り

1. LiveCygwinのZIPファイルをダウンロード
   
2. ZIPファイルを空白や日本語の入らない場所に展開(以下、 C:\LiveCygwinにアーカイブの中身があると仮定する。）
   
3. 次の二つのファイルをダウンロードする。
   
   
   
   1. nxtOSEKtools.tar.bz2
      
   2. nxtOSEK215.tar.bz2
      
   
   
4. ダウンロードしたファイルを２で展開した場所の下の usr/archに置く。
   
   
   
   • C:\LiveCygwin\usr\arch\nxtOSEK215.tar.bz2
     
   • C:\LiveCygwin\usr\arch\nxtOSEKtools.tar.bz2
     
   
   
5. C:\LiveCygwin\startup.bat をダブルクリックしてLiveCygwinを起動
   

以上となる。初回は、ツールの展開に時間がかかるけれど、ホームフォルダが残っていれば、次回からは起動は早くなるはず。
Windowsのデフォルトのホームフォルダはログアウトした時に消えてしまう設定の環境（私の職場だ！）では、startup.batの中を書き換えて、ホームフォルダのデフォルトを変更した方が便利だと思う。

二つのファイルをusr/archに置いた状態で、C:\LiveCygwinのフォルダの中身をCDROMに焼いておいてもいい。

どれだけ利用者がいるか不明だけれど、ご利用ください。

今回は外部ツールはまとめて別ファイルとして、nxtOSEKのバージョンアップ対応を簡単にしておいた。
（nxtOSEKを新しくする場合、ecorobot/tool_gcc.makの環境変数を書き換え、sg.exeをtoppers_osek/sgにコピーするだけだ）

インド タミールナドゥ州の風力発電

先月のインド出張で走る車の中から、風力発電プラントを見た。

もちろん、ここの設備がうまくいっているのかどうかは分からないし、現に、かなりの風車は動いていなかったように見えた。

こういった施設は広い土地がある場所だからという言い訳はせずに、できることは何でも大規模に実施する気概が、政府として必要なのだろう。

日銀引き受けなどという小さな話をせずに、思い切って、市中で国債を消化させ、数十兆円クラスの復興を未来を見据えてしていくことが必要なのでは？

国がなすべきこと

国民の生命・財産を守ることが最優先事項だ。

この目線で、しっかりと活動してほしいが、二次災害の恐れがある未曾有の状況に背筋が寒くなる。

知人と連絡が取れないままだけれど、個人に出来ることは祈ることだけ。

被災していなかったとしても、我々は偶然生きているにすぎない。
この世界の、どこで、どれだけの災害や事故・病気が発生するのか、自分では制御できないことには、ひたすら謙虚に、できるだけのことをするのみ。

幸運な人々は、それぞれの日々を精一杯生きていくことこそ、求められるのだろう。

無念にも亡くなられた方々のご冥福をお祈りします。

個人で出来ることということで、Googleがまとめた募金情報から自分がアクセスできるところを通して、義援金を送りました。

SystemCとNSL

OSCIの標準コンパイラ（というよりクラスライブラリ）が無料で使えるので、ソフトウェアとの連携があるverificationでは、SystemCはよい選択肢の一つです。
ただ、残念な言語仕様のおかげで、これを０から書くのはハードウェア設計者にはとても大変です。
VerificationにおけるSystemCの便利さをハードウェア設計者に「簡単に」提供したいと思って、NSLは、SystemCへの合成をサポートしています。
今日は、しっかりと時間を取って、家に引きこもり、SystemCを意識させないで、SystemCを用いるVerficationのパッケージを作っていました。

このパッケージを含むLiveCygwinはIP ARCHからダウンロードできます。

実は、パッケージ作成しながら、いろいろと合成されるSystemCの記述も調整したので、この方法をサポートするNSL COREは、20110305版以降となります。（上記、LiveCygwinには導入済み）

たとえば、このパッケージの中の一つの例題ですが、下のようなNSLコードを tut2.nslという名前で用意します。

パッケージにはMakefileが入っているので、

make T=tut2 scsim

とすると、NSLをコンパイルし、SystemCに変換したものをコンパイルしてくれます。
これを、
./tut2_sim 10000
として、10μSまでシミュレーションすると、

Hello World: value = 100, count = 100
count = 101
count = 102
bye: count = 103
SystemC: simulation stopped by user.

となります。たったこれだけです。
同じようなことを行う合成可能なハードをSystemCで記述しようとすると、とっても大変で、お勧めしません。もちろん、_display なんてのは合成対象ではありませんが、NSLの記述はハードウェアの裏づけを持ったシーケンス回路を生成しているので、1クロックずつ仕事をするようなハードウェアを書くのは、この例題とほとんど同じ記述で可能です。

魔法はMakefileの中にあるというのもあんまりなんで、少し種明かし。

Makefileでは、nsl2scの呼び出しとg++の呼び出しを行っています。
nsl2scでNSLをSystemCに変換し、それをg++でコンパイルしているというわけです。
OSCIで要求されるsc_mainもnsl2scが自動生成していますので、凝ったことをしたければ、自動生成したSystemCのメインルーチンに手を入れることができます。
ここで示したような、テキストベースのシミュレーションでは、メインルーチンを見る必要もないはずです。

Makefileを使わずに、自助努力をしようとすると、長いおまじないが必要です。
今回は、次のようにコンパイルしています。

nsl2sc tut2.nsl -scsim2 -target tut2 -split
g++ -I/usr/local/systemc-2.2.0/include -L/usr/local/systemc-2.2.0/lib-cygwin tut2_sim.cpp -lsystemc -o tut2_sim.exe


今回の例題NSLは、次のコードです。

declare tut2 simulation { }



module tut2 {

    reg count[8] = 0;

    wire value[8];

    func_self  start(value);



    count++;

    if(count==100) start(count);



    func start seq {

        _display("Hello World: value = %d, count = %d", value, count);

        _display("count = %d", count);

        _display("count = %d", count);

        _finish("bye: count = %d", count);

    }

}

努力の方向性

手っ取り早く答えだけが欲しいという若者が非常に増えている気がしていて、気になっている。

どんな分野でも、先をイメージして、関連事項を十分調査した上で、上達する方法を主体的に考え、こつこつと地道な努力をしないことには、一流の結果は出せない。魔法のポーションや銀の弾丸は現実社会にはないのだ。

たとえば、努力をまるでせずに、ちょっとネットで調べただけで、イチロー並にプロでヒットを打てるようになるとか、マイルス・デイビス並にトランペットを吹けるようになるとか、ありえないことくらい常識的に分かると思うが、勉強や仕事のことになると、これを夢見る人がいる。

簡単に手に入るものの価値は、限りなく低くなる。

いつの世の中でも真実である。簡単に手に入る事柄自体は、時代とともに変化するので、変化に負けない価値は物ではありえず、価値を手に入れる方法は、人が追いつかないほどの大量の努力しかない。


人材育成に関するこんな記事を見ると、学生たちが自分は忍耐強くないということを、全く理解していないようだ。

これって、彼らの努力が、社会的な忍耐強いというのと全く違うベクトルを向いているのか？

確かに、努力をしないための努力は、全く惜しまない人も散見される。。

ガリバーとビッグエンディアン

1726年発行のガリバー旅行記にビッグエンディアンの起源がある。

原典には6箇所ビッグエンディアンの記述が出てるけれど、リトルエンディアンとは言っていない。スウィフトは小さい側を smaller endといっているので、リトルエンディアンは、ここから取ったわけではなさそう。

インドに行くのは・・・

来月、インドに出張になるが、インドに行くのは思った以上に大変だった。

ビザが必要というのは聞いていたが、先方からのサイン入りの招待状が必要な上に、こちらの組織の推薦状も必要ということだ。
調べると、さらに政府からの許可証が必要なケースもあるらしい。

幸い、コンピュータ関連の学会では許可証は不要とのことだけれど、こんなに訪問だけでも障壁がいっぱいあるって、よほど来て欲しくないのですね～

EDS Fair 2011に出展します。

清水研究室は、1/27,28のEDS Fair 2011のユニバーシティブースに出展します。
お近くにおいでの方は、お立ち寄りください。

Linuxカーネル演習講座

4日間の速習コースなので、中心となるポイントだけを抜き出して講座を組み立てています。
今回は、全チームが最後の演習課題をクリアして、気持ちよく3日間の（私の担当部分）を終了しました。

RedHat6.0カーネルについて特に知りたいという受講生がいましたが、全体の講座マテリアルが（というか、主として参考文献が）まだ対応していないので、個別の口頭でのアドバイスになってしまいました。参考文献がないと、現在のレベルの演習を3日間で行うのは難しいので、今後どうするかは要検討とさせていただきます。（対応する市販テキストが出たら、実施可能ということです）

自分の用意したテキストと、市販の本が真逆のことを書いてある部分があって、受講生から「どちらが正しいのでしょう？」と質問され、自分ではわりとそそっかしい性格を自認しているので、調べてテキストを作っているはずなのですが、もしかしたら自分のテキストが間違った？と不安になったら、受講生がカーネルソースを見て、自分のテキストが正しいことを確認してくれました。（安堵）


受講生の皆さん、夜遅くまで、お疲れ様でした。

Transparent Hugepage?

詳しく追いかける時間はないので、タイトルだけしかみていないが、マイコミジャーナルの記事によると、RedhatがTransparent Hugepageを用意しているそうだ。

このあたりの経緯を少し整理しておこう。

• 2000年に私がLinux super pageを発表し、2002年LinuxカーネルMLに投稿した。
  
  このときのカーネルメインテナーのDave Mirrorなどは採用に積極的だったけれど、Linusが却下。
  Redhatからは、Alpha向けにリリースしたいのでボストンのラボで評価中との連絡が入った。
  
  
• その後、まもなく、当時のLinuxカーネルメインテナーの一人、Alan Coxのグループが、なぜかFreeBSD用にSuperPageを発表。
  
  
• TransparentでないTLB管理方法がHugepageとして発表、Linuxに採用された
  

という流れで、現在にいたるので、10年経ってようやく時代が追いついてきたのだろう。

例によって、オープンソースのコミュニティはオリジナル作成者を尊重しないので、私の名前が出ることはないかもしれないが・・・

私が関与しコードが採用されながらコントリビューション/著作権を無視されたプロジェクトには、

• Goto GEMM
  
• GNU GLIBC(libmの初等関数）：これは無視というよりIBMの遅いコードで上書き
  
• GCC (PDP11パッチ)
  

などがあり、もう、さすがにオープンソースへのコントリビューションはやめようと思っているが、自分が使う上で不便な場合にはやむなくソースまで追いかけるのは、これからも変わらないのだろうなぁ・・。

NSLとAllianceVHDLによるチップ製作第２弾

Rohm 0.18umプロセスで製造。
レイアウトは100％AllianceVHDLで作成。
スタンダードセルはAllianceのSXLIB使用。

VDECのリクエストにより、デザインルールチェックはCallibreで行ってエラーなし。

ＥＴ出展中

オーバートーン株式会社は、ＥＴに展示出展中です。
今日は、私もＥＴに行きます。

軽量PCとWindows7

いろいろと持ち運ぶものが増えた上に、電車で移動することが多くなったので、1.4kgのEeePCですら重く感じるようになり、VAIO-Xに乗り換え中。
SONY VAIO Xシリーズ

このマシン、軽量さにかけては文句ない。細かな操作性の悪さもあるけれど、我慢できない範囲ではない。ところが、搭載OSがWindows7となっていて、ここでいくつか問題が生じている。

一番大きな問題は、私が使っているMS Office97の動作が不安定であること。
特に、PowerPointは不意にフリーズすることがあるし、クリップギャラリーを開こうとすると、毎回フリーズする。頻繁にセーブしながらだましだまし使っているけれど、ふとしたことで、フリーズしたときに、編集結果を失ったりする。

次に、スライドにナレーションをつけて、ムービーにしようとしたら、Movie Makerがない？
Windows Live Movieなんとかをダウンロードするようにということで、ダウンロードしてみたら、システム環境が不足で起動できない。

結局、VISTA用のMovie Maker 2.6をインストールして作業中。

完全移行できるのかな。。ちょっと不安を感じながら旧来マシンと併用中。