6502互換CPU NSL版

6502互換CPUのm65をNSLで書き直しました。
シミュレーション上でWozのモニタ（Applie-Iのモニタ）を動作させるパッケージとしています。

コンパイルは、20110511版以降のNSLCOREが必要となります。
シミュレーションには論理シミュレータが必要です。私は、Icarus Verilogを使っていますが、シミュレーション構文はあまり複雑なものを合成しないので、大抵のシミュレータで動作すると思います。なお、Makefileを書き換えればSystemCでもシミュレーション可能だと思いますが、まだ試していません。

この規模の回路になると、行数が多くなるので、NSLCOREの非商用ライセンスが必要になります。

NSLはSFLよりもできることが多いのですが、SFLのレベルの構文もほぼ用意しているので、SFLからNSLへの書き直しは、機械的にできる軽微な修正となります。なので、あまり時間をかけずに可能でした。ただし、taskを複数利用するケースだけは注意が必要です。SFLのタスクは、それぞれがステージ中の特定の動作状況を表しますが、私（と私を参考にコードを書いた学生）のコード以外に１つのステージに複数のタスクを書く例はほぼなかったので、NSLでは、ステージとタスクを１つの手続きとしてまとめました。m65は複数のタスクと内部関数を使って、直行する制御を実現していたので、この部分の修正が単純な置き換えではできません。

色々とやり方を検討したのですが、タスク相当のレジスタを手続きの引数で与えることにしました。他にも状態と内部関数を利用するとか、いくつも代替手段はありますが、あまり手間をかけずに動作させることを優先しました。今後、もう少し概念を整理して、きれいな記述になる方法を検討してみます。

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);
        }
}