uml2sflテクノロジープレビュー版公開

ここ数日、開発していたuml2sflが、MagicDrawとBoumlの二つのツールのXMIを変換できるようになったので、とりあえず、テクノロジープレビュー版として、公開する。

Boumlはフリーソフトなので(見た目はあまりパッとしないれど)、簡単にお試しできる。

IP ARCH, Inc.のホームページから、SFL関連のセクションに行ってダウンロード可能。
(Windows版のみ)

XSLTコンパイラ

XSLTプロセッサによる変換が自由にできるようになったが、XSLTプロセッサの多くはJavaで書かれていて、環境設定が面倒なことと、XSLスタイルシートを生で出すのはあまり気が進まないので、XSLTコンパイラを探してみた。

候補は、いくつかあるが、

• SourceForgeのXSLTC
• XALANのXSLTC
• Microsoft WindowsSDKのXSLTC

の3つを試してみた。結果として、Microsoftのものを常用することにした。ただ、こいつは、.NETのライブラリにコンパイルするので、.NETのツールとリンクしないとスタンドアローンでは使えない。

仕方なく、VisualBasic 2008 Expressをダウンロード・インストールすることに・・・

コンパイルしたスタンドアローンツールでSAXONで処理した結果と同じものが得られることを確認。

と、ここまでは、一段落。

次は、再配布可能で、XMIエキスポートができるUMLエディタを探さなくては・・・

UMLからSFL(その3)

またまた少し修正。
今回は、操作を変更。visibilityによって、制御入力・制御出力を切り替えていたが、privateはやはりprivateな操作としたいので、次のように修正。

• public操作: 制御入力端子
• protected操作: 制御出力端子
• private操作: proc

合わせて、procのスケルトンも生成するようにした。
自動生成したSFLファイルは、ブログに載せるには大きいので、IP ARCH, Inc.の方にアップロードしたので、参照するには、

このリンク(mm.sfl)をクリックしてほしい。

UMLからSFLへの変換(その2)

UMLからSFLへの変換だが、もう少しUMLでのLSI記述の方法を調整し、図の形にした。

これに加えて、制御出力端子のinstr_argを自動生成させる。

変換結果の長いリストを再度載せるのは、割愛するが、今回の図の方が、ハード屋には違和感がないような気がする。

ＵＭＬからSFLへの変換(XSLT編)

小型CPU m8のUML図から、SFLのスケルトンに変換するXSLTスタイルシートを作成した。

図のUMLを自動変換して得られたSFLコードを↓に示す。
データタイプのbitがちと気持ち悪いのだけれど、それ以外は、まぁまぁ、納得できそうなUIではないかと思う。

もちろん、スケルトンができて終りではなく、これが始まりなので、コアコードをどのように開発するかを検討する必要がある。OMGのMDAのように、基本クラスに演算子を全部定義するようなマネはしたくなく、もう少し賢い方法を模索中。

declare m8 {
		  instrin ack;
		  instrout mr;
		  instrout mw;
		input datain<8>;
		output addr<8>;
		output datao<8>;
	instr_arg ack ( datain );
		}

declare alu8 {
		  instrin exe;
		input op<4>;
		input inA<8>;
		input inB<8>;
		output result<8>;
	instr_arg exe ( op,inA,inB );
		}

module m8 {
		  instrin ack;
		  instrout mr;
		  instrout mw;
		input datain<8>;
		output addr<8>;
		output datao<8>;
		 reg_wr acc<8>;
		alu8 alu;
		 reg_wr pc<8>;
	instr_arg mr ( addr );
	instr_arg mw ( addr,datao );
		{
		/* common operations */
		}

		  instruct ack {
			/* instrin operation */
		}
		}

module alu8 {
		  instrin exe;
		input op<4>;
		input inA<8>;
		input inB<8>;
		output result<8>;
		{
		/* common operations */
		}
		  instruct exe {
			/* instrin operation */
		}
		}

XSLTが面白い

単なるスタイルシートだと思っていたが、けっこうプログラマブルで、今まで、DOMやSAXでゴリゴリやっていたものの多くがXSLTで書けそうな雰囲気。

まだシリアライズの部分をどうコントロールできるのか、今一つ理解が進んでいないが、これをきちんとコントロールできたら、DOMで書いている今のアプリをXSLTに置き換えようかなと思っている。
(ただ、XSLTだと、独立したアプリにはならず、必ずXSLTプロセッサと一緒に使うことになるのが、気に入らないので、最終的にどうするかは微妙だ)

XSLTプロセッサと合せてコンパイルして独立アプリケーションにできる手段があるといいのだけれど、探せばあるのか？

それにしても、XSLTを書くためのフロントエンドの言語があった方がよさそうな記述性の悪さは何とかならないかな？

W3Cの規格書は例によって読めたものじゃないので、
XSLT: Mastering XML Transformations
のようなものを参考にしていこう。

実は、1.0のXSLTだったら、ポケットリファレンスが安い。

Xslt 1.0 Pocket Reference (Pocket Reference (O'Reilly))

FPGA Startup記事追加

スペースインベーダを動かした、MIDWAY GAME PLATFORM互換システムをFPGA Startupの番外編記事として追加した。

FPGAの合成に必要な全論理ファイルもダウンロード可能であるが、当然ながら、タイトー社の著作物であるROMイメージはパッケージから除外している。

オリジナルゲームを作成したり、ゲームの研究目的に使ってもらいたい。

midway.memにプログラムを16進形式でダンプしたものを入れて、他のファイルと共に合成すると、自動的にbitファイルに設定できる(最大8kB)。

懸案となっていたサウンドであるが、いずれにせよボード上に音を出せるコネクタがないので、今回は割愛した。

説明のスライドは、海外向けのままなので、(下手糞な)英語である。

ETロボコン NXT版公式環境になる・・・

かもしれない、nxtOSEK v209を使うように、LiveCygwin-nxtOSEKをアップデートした。

209ではC++クラスライブラリが強化されたそうだ。

だめだ腐ってやがる・・・

UMLエディタのMagicDrawをダマシダマシ使っているが、やはり、使い物にならないと結論。

XMIにエクスポートした時に、クラスにStereotypeの情報が付加されないのだ。
これは、今、やろうとしていることに対して致命的な欠陥であり、これ以上、このソフトと付き合ってもしかたないと思う。

代替え手段となるソフトとしてよいものは思い付かないのだが、umbrelloをcoLinuxで動かすのが、もっとも筋がよいかも？

SystemCにおけるboolとsc_uint<1>

SFLやVerilogを使っていると気にしていないが、SystemCを使うと、boolとsc_uint<1>がはっきりと違うものであることに戸惑う。

まるで、某HDLのbitとbit_vectorのようではないか？

ハードウェア設計者にとって自明なことを、こう杓子定規に言語屋の都合よいように解釈されても納得感がないのですが・・・
(私が某HDLが嫌いな理由の一つ)

SystemCでは、全部、sc_uintにしてしまえばいいかと思いきや、sc_clockは、boolにはマッチするが、sc_uint<1>にはマッチせず、テストベンチを統合する時に問題が発生した。

ということで、1ビットの信号はすべて、boolにしてみた。

sfl2vlは、20090327からのサポート、LiveCygwinもアップデート済。

続：SystemCへの合成

とりあえず、m8のSystemCシミュレーションは、Verilogと同じ結果を出すようになったので、最低限のことはできていそうだ。

SystemCでは、ヘッダファイルのコンストラクタの部分にサブモジュールの情報も必要となるため、入出力信号のプロトタイプだけ先にあればよい、SFLやVHDLと違い、モジュールの記述順序にクリチカルである。

呼び出される側のモジュールは、必ず、呼び出す側よりも先に書く必要がある。

これに注意さえしておけば(まぁ、他にも予約語の違いなどいろいろとあるにはあるが)、比較的簡単にテストベンチは作成できた。

20090326版のsfl2vlおよび、LiveCygwinで、この(m8をコンパイル・シミュレーションできる)バージョンを提供する(ベータ版)。

LiveCygwinのパッケージには、新に、SystemC-2.2.0のコンパイル環境と対応するm8のパッケージを追加した。LiveCygwinを起動して、

cd m8
make scgtk

と打つと、SystemCに変換した後、コンパイル・実行・波形表示まで行う。

m8/SIM/main.cpp

がテストベンチである。SystemCのまともなテストベンチを作成したのは、今回が初なので、効率悪いことをしていると思うが、ご勘弁願いたい。

m8単独のパッケージにもSystemC対応のファイルを同梱しておく。

SFLからSystemCへの合成

ベータ版のsfl2vlでサポートを始めたSystemCへの合成だが、今までは、小さな例題だけしか試していなかったので、m8をコンパイルする例題サンプルを作ろうと着手した。

ところが、これが、結構苦戦。

SystemCはVHDLなみに型のチェックが厳しく(C++だから当たり前だが)、boolとintとか、intとuintに互換性がない問題にことごとく嵌る。

しばらくバタバタしていたが、ようやく収束の兆しが見えてきた。
まだ、HPのパッケージをアップデートする段階ではない(そこまで安定していない)が、今週中くらいには何とかなるんじゃないかなぁ。。

中途半端な日本語化

Linuxで使うときには、Umbrelloで充分だったが、Windowsで、多少でも使い勝手の良いエディタが欲しくて(ここでいう使い勝手は、XMIエキスポートなどの機能のこと)、MagicDrawというUMLエディタを買った。

だが、使い始めて、ビックリ。

商用ソフトのくせに、文字化けで、日本語部分が読めない。
日本語が必要なわけではなく、ソフトがデフォルトのインストール設定で勝手に日本語にした部分(メニューリスト)が読めずに、ほとんど使い物にならない。

しかも肝心なXMIエキスポートは、ファイルメニューにあるはずのものがない(!)。
一度表れたことがあるので、何かの設定なのかもしれないが、メニューが読めないので、探す気にもならない。
オプションで、常にXMIを出力として、なんとかしているが、これも何だかなぁ・・・

ふと思いついて、オプション画面の中から、言語設定を探し出し、「English」に設定を変えたら、まともになった。(もちろん、全部英語になるけれど)
XMIエキスポートはあいかわらずだが。

金を払って買ったソフトで、こんな中途半端なものは勘弁してほしいものだ。

8bit 小型CPU m8を新構文で+インデクスレジスタ導入

新しく導入した構文の例題として、m8を新規構文で書き下ろした。
やはり、新しい構文は読み易いと思う(←手前味噌)。

ついでに、m8にインデクスレジスタを導入したバージョンも入れてある。(m8x.sfl)
アセンブラは変更していないので、インデクスレジスタを使うプログラム例題はすぐにはできないけれど、こんなに僅かな修正でインデクスレジスタのサポートもできちゃうんだという点に注目してほしい。

SFL言語で記述した旧来のCPUを m8-SFL.sflとalu8-SFL.sflとして比較のため維持。

これからは、新言語で行こう♪

sfl2vlの新しい構文

procとfunctionという新しい概念を入れる。
新しいといっても、functionはinstrselfの異形であり、
procは、stage+taskの簡易版である。つまり、functionは同一クロック内でのアクションを定義し、procは起動した次のクロックにおけるアクションを定義する。
1クロックで終了するfunctionと異なり、procは明示的にfinishするか、別のprocもしくはstageを起動するまで、実行を続ける。

どちらも、構文上の分り易さをねらったものだ。

functionを定義するには、

func_name 名前(引数リスト)；

で定義する。引数リストには、sel変数を指定する。

procを定義するには、

proc_name 名前(引数リスト)；

で定義する。引数リストには、レジスタ変数を指定する。

実行本体は、制御実行文として、
function 名前 アクション
proc 名前 アクション
のように記述する。

これらを用いる例を↓に示す。

module t {
 input a;
 output f;
 sel b,c;
 reg d,e,g;

func_name x(b,c);
proc_name y(d,e);

{  x(a,a);  } /* 共通動作で、function xを起動 */

function x { f= b&c; y(b,c);} /* xから、proc yを起動 */

proc y { g := d|e; if(g) finish;} /* gが1ならyをfinish */

}

プロトタイプはできているが、もう少し確認してから、アップロード予定

追記

procやfunctionの書式を使うと、instr_argという書式が不恰好に思えてきて、instroutやinstrinなどの引数定義をfunc_nameに合わせてみる。
(従来通りのやり方も使える)

declare文では、例えば、

declare test1 {
input a,b;
output f;
instrin exe(a,b);
}

のように、従来のように、引数を別に記述していたのに比べて、
記述量も減るし、分り易くなったと思う。

instroutも同様の拡張をした。