UMLで書くCPU その2

小型8bitCPUのm8をUMLで記述。
命令数は少し減らしているけれど、UMLtoNSLとNSLOvertureを使うことで、論理合成可能なファイルが得られる。


ただ、2種類のCPUを書いて思ったのだけれど、UMLでコードを書くのは、あまり便利ではない。開発を不便にしている原因としては、主として、エディタの問題と、可視性の問題の2つがある。

普通にコードを書くのであれば、エディタで検索やタグジャンプしながら作成した方が、早い。

やはり、UMLはスケルトン生成までにしておいた方が、現実的か？


ともかく、UMLからCPUが合成できるようにはなっている。

コメントのネスト

SFLでは、コメントはネスト可能ということで、
/* hogehoge
/* nested hogehoge
*/
*/
という記述が書けた。
NSLもそれを踏襲していたけれど、*/と/*を間違って、全部がコメントとなっているケースを作る人がいて、やはり、ネストはやめた方がいいかもしれない。
コメントは基本として人が書くので、自由度は少なくしておこう。

20100329版から、NSLでは、コメントネストを禁止します。
SFLは従来通り。

VB-2008 comboboxの初期化

Comboboxを置いたら、最初に初期値を入れておきたいと思うのが人の性だと思うが、VB-2008では、この単純な要求をスマートに解決する方法がない。

いろいろと調べていたが、スタートアップ記述を書くのが、それらしい解決かな？

プロファイルで操作できるほうが、それっぽいのですが。。

PapyrusUMLエディタのプリファレンス設定

PapyrusUMLのオペレーションの記述で、パラメータ名が図に表示されないのが
気持ち悪かったのですが、
windwos->preference
で
Papyrus->Diagrams->Class Diagram->Operation
において、添付のような設定で、名前を図に表示できるようになります。

現在開いている図には反映されないので、プリファレンスを設定したら
一度図を閉じてから、再度開いて見てください。

UMLtoNSL: UMLコメントのサポート

UMLtoNSLで、PapyrusUMLで記述したコメントをNSLソースコードに反映するようにした。

書かれたコメントは編集なしで直接ソースコードに反映させるので、
#define ABC 123
なども、そのまま出てくる。

そこで、本当にコメントを書きたい場合、NSLコメント形式で記述する。
たとえば、

// これはコメントデス

など、//から始まる行はコメントであり、 /* .... */ で囲われた部分もコメント扱いになる。

なんで、こんな仕様にしたかというと、UMLではマクロ定義を記述する場所がなさそうなので、マクロをなんとかサポートしたいと思ったからである。

パッケージのコメントは、ファイルの先頭部分に出力され、各クラスのコメントは各クラスのdeclareの前に出力される。

NSLtoUML 2010-03-27版からのサポート

XSLTとdocument関数

XSLTは、document関数で外部ファイルを読み込むことができるのだけど、絶対パスならともかく、相対パスで読み出しをかけるときの、ファイルの起点が変換XSLシートのある位置だという。

ユーザーデータを処理する用途だと、使い難いこと、この上ない。

XmlResolverで対応できるというのだけれど、例題がネット上に少いし、(MSDNを含め)情報が古く間違っているものが多い。

絶対パスだと何でだめかというと、ポータビリティの問題なのだ。

もう少し研究要。


絶対パスなら、UMLだけで、SN/X互換CPUは完成しているけれど、絶対パスでは、配布しても役に立たないので、相対パスを何とかしようと、悪戦苦闘中。

追記

document関数に基底URIを指定することで対応した。
だけれど、基底URIにトップノードを指定するとNGで、一工夫が必要だった。

ともあれ、無事動いてよかった。

UMLtoNSLはココからインストール可能

NSL profile for UML

PapyrusでのUMLクラス図作成を助けるものとして、NSL profile for UMLを作成してみた。

このプロファイルを用いて作成したXMIをNSLに変換するには、2010-0322版のUMLtoNSLが必要となる。

先日の開発ステップバイステップのドキュメントは、プロファイルを利用するようにアップデートしておいたので、下記説明とともに参照いただきたい。

ただし、Windows .NET版は、document関数がセキュリティ上許可されないので、動作しないようだ。Java版のみ、正しく動作するはず。（プロファイルの参照は、相対パスのhrefとなるため、実行パスの設定の問題かもしれないが・・）
やはり、実行時パスの問題だった。カレントディレクトリを実行時に設定することで、変換OK。

プロファイルといっても、中身を見れば一目瞭然で、NSLの基本データ型が定義されているだけで、あまり便利とも言いがたいが、入力ミスを避けるためには、多少、役に立つかもしれない。

使い方は、Papyrusのワークスペースに上記のファイルをダウンロードし、新規プロジェクトを作成するときに、パッケージに上記プロファイルを適用するしたときに、outlineのプロジェクトトップを右クリックし、Import Package→Import Package from fileと進み、ダウンロードしたファイルを指定して、NSLにチェックを入れる。

そうすると、属性を定義する時に、typeの項目の＋記号をクリックし、NSLプロファイルの中からデータタイプを選択することができる。（こんなのは、手で入力した方が早いと思うが、Papyrus流は全て選択で進むのだ）タイプ名にNSL::まで入れると、NSLの型のリストがプルダウンメニューに出てくるので、必要な型を選択できる。属性の可視化は、入出力はpublicだが、内部端子はprivateに明示的に変更しておく必要があることに注意。

XSLT的には、Papyrusにおけるプロファイルの参照は、クロスファイルの参照となるので、案外難しかったが、一応ファイルは生成されているようだ。

PapyrusによるNSL開発方法 ステップ・バイ・ステップ（３／２３改訂）

多少、手順を知っていないと、うまく合成可能なコードができないので、ステップを追った手順書を作ってみた。

PapyrusによるNSL開発ステップ・バイ・ステップ（PDF)　３／２３改訂

この手順通りに作業すると、論理合成可能なNSLが作成できる。

現在、NSLの機能のうち、Papyrus対応をサポートしていないものに、interface宣言がある。ArgoUMLでは、ステレオタイプで指定するようにしたが、Papyrusのステレオタイプは、プロファイルを適用しないと使えず、少し不便なので、別の方法を考えるか、プロファイルを本格的にサポートするべきか決めかねている。

クラスをprotectedに宣言したら interface宣言とみなすなどとしてもいいのだけれど、Papyrusではクラスの属性変更がダイアグラムから分からないので、多少不便。→ protectedクラスはinterface宣言を付けるようにしました。（３／２３）

Papyrus UMLからのコード合成

UMLツールは、ツールごとに、生成するXMIが微妙に異なる。
これは、メタファイルとして「それらしい形」になっていればいいという判断だろうけれど、XMIから、いろいろと処理を展開する合成系には不便な話だ。そもそも、UMLとXMIに関しては、XMI2以降は標準がなくなってしまい、あくまでもメタ情報ということになっていまっているので、混乱は今後も続くのだろうと思う。

UMLtoNSLのコード合成は、ArgoUMLとMagicDraw、BogoUMLなどに対応していたが、このところPapyrus UMLの可能性を探ってきた。

とりあえず、それなりのコードが出るようになった（気がする）バージョンとして、20100320版をアップロードしておいた。

Papyrus UMLの気持ち悪い点は、３つほどあり、

1. 操作のvisibilityは、デフォルトでパブリックが指定されているようにプロパティウィンドウのチェックボックスで見えるのだけれど、実際には、visibilityは出力されない
   
2. 初期化をクラス図上で明示しなくても、勝手にdefaultValueのタグが出力される
   
3. 初期値を保持するタグが、UML 2.Xのドキュメントと異なる
   

などあって、上記のバージョンでは、これらに対応している。

Papyrus UMLには、よい点もたくさんあり、操作にopaqueBehaviorが指定でき、UMLクラス図でNSLのコードが書けるし、UIは気持ち悪いことも多いけれど、それなりに使えるものには仕上がっている。

nsl2vl: splitオプション

VHDLとSystemCでは、必要性からモジュールごとばらばらのファイルに分割するsplitオプションを用意していた。

従来、このオプションは、同一ディレクトリにファイルを展開するようにしていたけれど、ディレクトリを指定・作成して、その中に展開したいニーズもあるので、splitを指定したときに -o で出力先ディレクトリを定義できるようにした。

Verilogでは特に分割の必要性はなかったけれど、これだけ特殊扱いする理由もないので、Verilog時出力時も同様にsplitオプションを有効にした。

このサポートのため、スクリプトを一新。$0を解析して、モードを変更するようにした。

20100318版からのサポート

再現性に乏しいエラー

完全に再現するものは、比較的追いかけやすいのだけれど、自分のところで、再現しない問題は追いかけるのも難しい。

マシンによって結果が違うことから、おそらく、変数の初期化の問題ではないかとあたりを付けて、とりあえず、対策（のつもり）

NSL: variableの左辺サブレンジ転送サポート

NSLでは、通常の信号は、左辺にサブレンジを指定しての転送は禁止している。
これには理由があって、NSL/SFLの文法では、コードの複数の部分において、端子に対する転送が記述可能なので、サブレンジ単位では転送条件を制御することができないからなのだ。（サブレンジ転送をする用途では、複数の異なるビットに対する転送を同時に行う場合がほとんどだが、重なりの検出、同時でない場合の対応等々、条件が数多く発生し、好ましくない）

VerilogやVHDLでは、代入を１箇所でしか記述できないので、サブレンジに代入しても、処理系は混乱がない。この方式だと、動作を完全に分析した後で、ほとんどネットリストに近い形でコードを書かなくてはならない欠点があるのだ。この欠点はとんでもなく大きく、生産性を著しく下げると思うのだけれど、ユーザは、その場その場で、自分に都合の良い解釈をするので、NSLでサブレンジ転送ができないことを欠点と捉える場合がある。

そこで、varilable変数に限定して、サブレンジ転送をサポートすることにした。もともと、variable変数は、ハード的な実体と１対１にはなっておらず、コンテキストに応じて、必要な端子を自動生成するので、左辺にサブレンジを持ってきても、そういう端子を自動生成すればいいだけなので、お気楽である。

このバージョンでは、さらに、variable変数は初期化しないで使った場合に、初期値０とする変更、プリプロセッサの引数変更も同時に行った。（プリプロセッサ対応の、スクリプトを追加：nsl2vl, nsl2vh, nsl2sc）

おっと、もう一つ忘れるところだった。

このバージョンから、NSLでは、moduleでの入出力端子の記述を禁止します。
入出力端子等は、declareに記述してください。


20100313版からのサポート


サブレンジ転送の例題は下記↓

declare subrange interface {
input a[8];
output f[8];
}

module subrange {
variable v[8];

 v[3:0] = a[7:4];
 v[7:4] = a[3:0];
 f=v;
}

XSLTコンパイラ

Java版のコンパイラとしてApacheのものを使っていたが、JDKに標準搭載されているということだった。コンパイラモジュールのパッケージ名がJDK搭載時に変わったので、JDKでコンパイルし直さないと過去コンパイルしたものは動かなかったが、JDK標準ということで、余分なjarを添付する必要がなくなり、シンプルになった。

UMLからNSLへの変換ルーチン（Java版）は、JDKベースに変更済み

NSLプリプロセッサ

実は、Cのプリプロセッサと出力形式を互換としているので、sflpp.exeの代わりにcpp.exeを利用可能なのだけれど、独自プリプロセッサの必要性も結構あるので、もう少し機能拡張中。

まだ、リリース前だが、-Iと-Dのオプションをサポートした。次の改訂で入る予定。-Iで指定できるインクルードパスはとりあえず１２８個を上限としておく。
-Dは、マクロの定義だが、

-DSOMETHING

として、マクロ定義だけするケースと

-DANYTHING=BOO

と、定義に値をセットするケースの両方をサポート。
注意すべき点として、-Iも-Dもオプション中に空白は許さない点だ。WindowsやMacOSXなど、空白をディレクトリ名やファイル名に使うことのあるOSでは、フルパスを指定するのは難しいので、相対パスの利用が基本となる。

テストをしてみたが、ちゃんと動いていそうだ。ただ、現在の起動スクリプトには、プリプロセッサにオプションを渡す方法がない。これは、今後の課題としておこう。


追記：
とりあえず、下記のスクリプトでなんとかなりそう。もう少し改良が必要だけれど、当面、この方針でいこう。

#!/bin/bash
if [ $# -lt 1 ]; then
echo "Usage: nsl2vl filename.nsl {-neg_res|-neg_clk|-sync_res|-O{0|1|2}|-v}"
exit 0
fi
SFL2VLEXE=sfl2vlbin.exe
SFLPP=sflpp.exe
exearg=""
pparg=""
name=$1
shift
for arg in $*
do
args=${arg:0:2}
        case $args in
                -I)     pparg=$pparg" "$arg ;;
                -D)     pparg=$pparg" "$arg ;;
                *)      echo defaut! ; exearg=$exearg" "$arg ;;
        esac
        shift
done
echo "${SFLPP} $pparg $name | ${SFL2VLEXE} $exearg -nsl -o `basename $name .nsl`.v "
exit $?

サブモジュールのインスタンス数

パピルスでUMLを書いていると、関連で接続した子クラスに多重度を設定したくなる場合がある。
サブモジュールのインスタンスは、今まで１つずつ設定していたが、UMLと合わせて、多重度を表記できるようにした。

これを使って、下のようなモジュールを書くことが出来る。（例はあまりよくないが）

20100310版より、NSLOverture, UMLtoNSLで対応。

declare subm {
 input a;
 output f;
}
declare mm {
 input xx[4];
 output yy[4];
}
module mm {
 subm mx[4];
 integer i;
 variable v[4];

 for(i=0;i<4;i++) mx[i].a = xx[i];
 v=0;
 for(i=0;i<4;i++) v = v | (({0b000,mx[i].f})<<i);
 yy = v;
}