夏の出張ラッシュ

普段、なかなか出張する時間的余裕がないので、夏や春にまとめて海外を含む用事を済ませる。
今年も8月中旬から、タイで集中講義を行い、その後、京都、大阪、兵庫、岡山と出張が続いたが、ようやく一段落だ。

出張中は、ネットも不自由なので、メールは個人宛の緊急性の高そうなもののみ携帯から読み出していたので、これから、8月以降のメール処理を順次始める。

そうこうするうちに、すぐに、次の仕事のピークが来るので、ゆっくりする暇はないですね～

Out of Order実行 SN/X 完成

一応、自分で用意している４つのテストケースは完動したので、完成としておこう。

最終的に、LD/ST専用にインオーダーのリザベーションステーションを作ったり、各種事象の同時発生対応コードを入れたりと、コード量はずいぶん増えて、現在、794行。

かろうじて800行は切った。まぁ、これでも、Out of Order実行CPUとしては、極小の部類だと思う。

主要諸元は以下の通り


　

CPU アーキテクチャ	SN/X
リザベーションステーション	ALU（2エントリ）
リザベーションステーション	BRANCH（2エントリ）
リザベーションステーション	LD/ST（2エントリ：インオーダー）
リオーダーバッファ・リネームレジスタ	８エントリ
ストアバッファ	２エントリ
コード行数	794行
開発期間	実働４日
使用言語	NSL

最後まで悩ませたのが、SORTの例題で、実行結果のメモリがおかしいというもの。これは、メモリまでアウトオブオーダーにしていたので、STの後にLDで同じアドレスを読み出すケースで、LDをSTよりも先に実行してしまい、値を誤っていた。LD/STのリザベーションステーションを1エントリにするという方法もあるけれど、一応、インオーダー２エントリとして対処。メモリをアウトオブオーダーに実行すると、性能上は非常に優れているのだけれど、演算結果がおかしいのでは意味がないね。

インオーダーCPUは、順番に実行するので、リソースの競合はあらかじめ避けるように設計するのだけれど、アウトオブオーダーの場合には各ユニットが勝手に実行するので、同時発生の競合や、読み出し・書き込み同時の場合に、スルーでデータを渡すのか、待たせるのかなど、個別に詳細な検討が必要だ。

それに、何より、結果がおかしい時のデバッグが難しい。
お勧めは、命令リタイヤはインオーダーだし、発行もインオーダーなので、まずは、リタイヤを追いかけて、命令結果を見て、その後、リタイヤアドレスから命令発行場所を探して、解析を行うというもの。

命令発行と命令リタイヤが１命令ずつなので、アウトオブオーダーにしたからといって、大きく性能が向上するわけではないけれど、原理を理解するための教育目的CPUなので、その目的には十分な効果があると思う。

Out of Order実行のSN/X

500行に収めるのはあきらめ、NSLに非商用ライセンスを設定し、一昨日、3時間、今朝、1時間ほどデバッグ作業の時間が取れたので、少し動きはじめた。でも、メモリへの格納値が微妙(？)に違う。

インオーダーのCPUと違い、デバッグで命令を追いかけるのは、結構大変な作業だ。
デバッグの続きは来週後半かな。。

現状、661行で、(それなりに)動作している。たぶん、アウトオブオーダーCPUとしては、世界最小ではないかな？ :-)

/home/SNX> wc snxo.nsl
  661  1647 15510 snxo.nsl

問題のメモリログは、下記。もともと、SN/Xはメモリ待ち時間は0なので、単にアウトオブオーダーにすると、(分岐でリオーダバッファフラッシュが入るし)実行時間は長くなるのだけれど、レジスタリネーミングしているので、レジスタ数の少ないSN/Xには、OOO実行は向いている気がする。

HALTED at      122 clock
00000000: 0001 0002 0004 0000 0000 xxxx xxxx xxxx
00000008: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000010: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000018: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000020: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000028: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000030: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000038: 000b xxxx 000b 0000 000b 0001 0003 0002
00000040: xxxx 0003 xxxx xxxx xxxx xxxx xxxx xxxx
00000048: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000050: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000058: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000060: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000068: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000070: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000078: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

PC:0006 /home/SNX> ^simo^sim
tail -20 sim.log
PC:0003 st  $1,   0($0) -- $0:0010 $1:0006 $2:0003 $3:00
PC:0004
HALTED at      109 clock
00000000: 0006 0002 0004 0000 0000 xxxx xxxx xxxx
00000008: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000010: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000018: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000020: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000028: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000030: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000038: 000b 0000 000b 0001 000b 0002 0003 0003
00000040: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000048: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000050: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000058: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000060: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000068: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000070: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
00000078: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx

NSLとAllianceVHDLでチップ試作

NSLで論理を作成し、AllianceVHDLでレイアウトをしたチップが上ってきた。
1.2um 2層メタルのミニチップだけれど、デザインフローの確認には充分。

ただ、2層メタルなので、クロックツリーの作成など、次のステップとなる部分は確認できず、以降の試作で確認予定。

80ピンQFPのパッケージ品で動作確認する必要があるので、確認回路の設計をしないといけないですね。

ベアチップに顕微鏡でピンを立てて、動作確認する方が、私好みなのだけれど、「できる気がしない」などと言う奴に、やる気を出させるアイデアはないですか？

NSL: SystemCシミュレーションスケルトン生成

SystemCのシミュレーションスクリプトは、
慣れれば難しくはないのだけれど、
慣れるまで、少し作成に時間がかかるので、
NSLからスケルトンを生成できるようにした。

#include <systemc.h>
#include "inc16.sc"
#include <stdlib.h>
sc_clock m_clock("m_clock",10,0.5,0,false);
sc_signal<bool> p_reset;
sc_signal<sc_uinit<16> > a;
sc_signal<sc_uinit<16> > q;
sc_signal<sc_uint<1> > exe;

inc16 inc16("inc16");

static int ctrl_clock=0;
SC_MODULE (c_clock) {
        sc_in<bool> m_clock;
        void do_reset() {
                ctrl_clock++;
                if(ctrl_clock==0) p_reset=1;
                if(ctrl_clock==1) p_reset=0
        }
        SC_CTOR(c_clock) {
                SC_METHOD(do_reset);
                sensitive << m_clock.pos();
        }
};

int sc_main(int argc, char *argv[])
{
        int stop;
        if(argc>1 && (stop=atoi(argv[1])<=0)) stop=1000;
        sc_trace_file *tf = sc_create_vcd_trace_file("inc16");
        sc_trace(tf,inc16.p_reset,"inc16.p_reset");
        sc_trace(tf,inc16.m_clock,"inc16.m_clock");
        sc_trace(tf,inc16.a,"inc16.a");
        sc_trace(tf,inc16.q,"inc16.q");
        sc_trace(tf,inc16.exe,"inc16.exe");
        c_clock cclk("cclk");
        cclk.m_clock(m_clock);
        inc16.p_reset(p_reset);
        inc16.m_clock(m_clock);
        inc16.a(a);
        inc16.q(q);
        inc16.exe(exe);
        sc_start(stop, SC_NS);
        sc_close_vcd_trace_file(tf)
}

DeSmetCコンパイラ

MSDOSの時代、一世代を築いたコンパイラにDeSmetCがあった。
途中から、ANSI C互換文法もサポートし、利用者がかなりいたと思うが、DOSの時代が終わるとともに消え去っていた。

FreeDOSで小さなアプリを作るため、x86の16ビットコンパイラをいろいろと探していたが、どうも、思ったようなものがなかった。

やはり、ここは自分で移植しないとだめかと、ほぼあきらめかけたとき、DeSmetCがオープンソース（GPL）になっていたことが分かった。

このコンパイラは、非常にコンパクトなので、変更したりするのも便利だし、何より、ライセンスを気にせず使えるのがうれしい。

少し落ち着いたら、VMでFreeDOSを動かして、動作確認をしてみよう。

LiveCygwinにnxtOSEK同封

教育に使うには、LiveCygwinは便利なので、サーバー容量の関係で削っていたnxtOSEK同封版を復活させた。

複数のLiveCygwin環境をメンテナンスするのは、もうやっていられないので、全部入りとしてしまったので、これまで最大の大きさになった（115MB）。

それでも、これ一つ持ち運べば、ソフトがインストールできないマシンでも、たいていの教育はできてしまうので、便利である。

搭載ソフトウェア：

1. 例題を実行するため必要最低限のCygwinバイナリ
   
2. GCC
   
3. EDAtools
   
   
   
   1. NSL CORE: i386/win32 コマンドライン版
      
   2. UML2NSL: Java コマンドライン版
      
   3. Icarus Verilog
      
   4. GTKWave
      
   5. SystemC
      
   6. AllianceVHDL
      
   
   
   
4. LEGO NXT向けの開発環境　nxtOSEK(v2.13)
   

アウトオブオーダー実行CPUを500行以内で

演習で利用するため、NSL CORE評価版の行数制限で、なんとかアウトオブオーダー版SN/X CPUを作成しようと検討中。

スーパースケーラSN/Xは300行ちょっとで記述できるけど、OoOを500行に収めるめどは、まだ立っていない。

各ユニットのリザベーションステーションと、リオーダバッファをモジュールで共通化するなど、まだ、手段はあるので、あとちょっとをなんとかしたいものだ。

不安定なGoogleDocs

現在、執筆中の文書が、テキストファイルのバイト数にして、約100KB程度になってきた。

編集場所を選ばないという理由で、Google Docで書き始めたが、この量になると、かなり不安定。

1. 目を離した隙に、全テキストが消える！！　数度経験。→　Ctrl-Zでたいてい回復
   
2. 半角英数を入力すると、勝手にOverwriteモードになってしまい、後ろのテキストを消す。　→　打ち直し
   
3. カーソル位置が勝手に変わり、見つからない。→　マウスでクリックしなおし
   
4. インデントとインデントのテキストの合間に、普通のテキストが入らない　→　HTMLを直接編集
   
5. インデントの方式が場所場所で、違い、しかも、枠が印刷されてしまう場合と、されない場合があり、あとから修正できない。→たぶん、HTML編集が必要。
   

最初の不具合以外は、我慢できない範囲ではないけれど、問題は、GoogleDocsから持ち出すフォーマット変換がオオバカで、まともなファイルにならない点にある。

テキスト形式は中でも一番まともだけれど、全部、フォーマットやり直しかぁ。。

FET売り切れ

先日紹介したFETを発注しようと、職場の担当部署に見積もりをお願いしたら、なんと、売り切れで必要個数が入手できないそうだ。

たくさんあると思っていたが、ブログで紹介する前に、見積もりをお願いしておくべきだったか・・　;-o

とりあえず、在庫がある限り、発注をお願いしておいたが、よく考えてみれば、別に急ぐ必要はないので、数がそろってから、ゆっくり発送してもらえばよかった。（もう遅いけど）

少し、トランジスタの数が減ったので、アーキテクチャをシュリンクする必要がありそうだ。