OSEK/VDX演習用実装

OSEK/VDXは国際標準になっている組込み用OSです。

このOSを用いた演習を行なうには、通常は組込みマイコンの評価キットなどを用います。

しかし、評価キットは案外寿命が短く、MPUもボードもあっという間に入手難になったりするので、演習の組み立てに苦労します。

OSEKはせっかくの国際標準なので、APIより上の層の演習を行なうには、マイコンである必要もないだろうと、演習用にCygwin/Linuxへ実装することにしました。

実装のターゲットOSの選択として、ToppersのATK1か、OpenSource RTOSのTrampolineを調べていましたが、日本で行なう演習には、コメントが日本語で入っているToppersの方が簡易だと判断し、ToppersATK1をCygwin/Linux上に移植しました。

移植したコードは、例によって、IP ARCH, Inc.から配布します。

割込みは、シグナルを捉えて実装していますが、Cygwinは非同期IOでSIGPOLLを発生させることができないようなので、非同期の割込みはタイマとSIGINTの二つで、SIGUSR1とSIGUSR2をアプリケーションが発行可能な割込みとして割込みエントリを定義しています。

この移植にあたっては、友人のKSU水野先生のnxtOSEK移植コードを参考にさせていただいています。

4004設計追体験

MYCOMジャーナルにタイトルの記事が出ていた。

面白そうだなと思い、設計その1を読んだら、脱力した・・・


著者は、設計のこと分かっていないんだろうな。

設計その2でゲート数比較だけで、回路構成を検討しているので
最終的にどちらの回路が使われるかは不明だが、このレベルの
設計者なら、私なら雇わないね。

CELLの歩留まり

CNETの記事によると、CELLの歩留まりは10％～20％程度とIBMが言及したとしている。

ということで、記事にリンクされているEE TimesのTom Reevesへのインタビュー記事を読んだ

こちらは、じつはCELLの話のような小さなことだけを言っておらず、
半導体の大きなトレンドの話をしていて、じつは、ずっと興味深い。

高速ロジック素子としてのバイポーラが100Wに達して、
次のステップとしてCMOSに移行してきて、それもすでに100Wに達し、
次なるステップが求められている。

まだ解が見つかっていない32nm以降の電力制御についての新しい方式の
研究開発が急務というのが、こういった流れからも分かる。

また、記事の最後に、

Clarification
Tom Reeves, IBM’s VP of semiconductor and technology services, said he was not making any specific references to past or current Cell yields in an executive insight interview that ran last week. He was, instead, referring to large die yield challenges in general and the successful leverage provided by logic redundancy strategies. IBM does not release product specific yield information. This clarification was made on July 14, 2006.
Click here!

と、書かれていて、特定のチップ（CELL）の歩留まりについて、述べたものではなく、大きなダイのチップに対する冗長性の必要性を述べたに過ぎないと注意書きがある。

ETロボコン

7月1,2日に開催されるETロボコン
私は実行委員なので、今日の設置準備から作業開始である（21時終了予定）が、明日の集合時間は午前8時（！）

家から開場までは2時間はかかるので、今日は東京に宿泊しよう・・
（事務局が宿泊費を出してくれるかは不明・・）

今年の規約は去年のチャンピオンシップに準じてルールが設定されたことと、難所を難所とすべく多少コースに手を入れた。

元々、チャンピオンシップルールは私が提案したものだが、決定時には色々と議論があったものの、シンプルでいいルールだと自画自賛（笑）

今までずっと忙しく、コース設計時にはほとんどお手伝いできなかったので、実物コースとの対面は私は今日が初めてとなる。設置の便利と再利用性を考慮したコースになっているということだが、果たしてどんなものやら・・

WindowsXPコマンドラインのパイプ

LiveCygwinを授業で使おうと、動作確認をしようとしたら、
職場の計算機室のマシンでは動かない！？

原因追求していったら、職場のWinodwsXPのコマンドラインでは、パイプ'|'が使えない！？

パイプを使わないと、中間ファイルをたくさん吐き出さなくてはならず、汚らしいが、使えないものはしかたない。

でも、なんでパイプが使えないコマンドラインなんてのがあるんだろう？

ちょっと検索したが、これに相当する問題点は探しきれなかった・・sigh

C言語のパーサー

Jutta DegenerがANSI CのYACCとLEXのパーサーを公開している。

これ、少し手を入れると、BISONとFLEXが問題なく通る。
（FAQにはshift/reduce conflictが1つ出ると書かれているけど、%precを使って逃げられるので、エラーなしのファイルにはすぐ変更可能）

BISON・FLEXで通る文法ファイルがあれば、色々とやってみたいことがあるので、まじめに読んでみよう・・

ところで、このパーサー、著作権表示がまるっきりないんですけど・・

（日本の著作権法は何もしなくても、著作権が生じるけど、アメリカでは、積極的に著作権を主張しないかぎりパブリックドメイン扱いになるはず。これでいいのかなぁ？）

VHDL:真理値から論理値への変換関数

VHDLで当たり前のように欠けていた（200Xではextraパッケージに入ったので過去形だがFPGAベンダーツールでは未サポート）ものに、真理値から論理値への変換関数がある。

論理設計者は真理値と論理値を自由に交換して、当たり前のように使うのだが、VHDLでは厳密に型が一致しないと利用できないので、真理値と定義されたものを自由に論理の中で信号としては使えない。

実は、簡単な関数で変換できるのであるが、こんな当たり前のものが何でIEEEの標準ライブラリに最初からないのか、とっても不思議なものだ。

function to_std_logic(b: boolean) return std_logic is
begin
if b then return '1'; else return '0'; end if;
end to_std_logic;


上の関数は真理値を論理値に変換する。
パッケージとして自分のプロジェクトに追加するか、architecture定義の中に書くことで利用できる。extraパッケージがベンダーツールで利用可能になる将来を考えればパッケージ化しておいたほうが役に立つ。

to_std_logicという関数名は他の論理値への変換関数と同一の名前である。VHDLでは引数の型が違えば同一関数名を利用しても問題にならない。多様体を許しているからである。

この関数はFPGAベンダーツールで普通にコンパイルできるので、少し仕事が楽になった。std_logicとstd_logic_vectorの違いも標準関数を呼び出し、何とかできるので、どんどん記述が長くなり人の読むものではなくなるが、一応、VHDLでもVerilogHDL並みの記述は作成できる（読みたくもないものを書くなんてとんでもなく、私にとって、あくまでもVHDLはアセンブラもしくは中間言語以上のものではないが）ことになったので、VHDLターゲットの仕事もこれで請けられそうだ。

ｓｆｌ２ｖｈの最適化処理

やはり、人任せにせず、まじめに最適化VHDLコードを出すことを考えた。
一応、基本設計は終了し、基礎実験において、きちんと正しく動作しそうなことは分かったが、最適化VHDLを出力して欲しいという要望はほとんどないので、気が向いたときに少しずつ作業を進めることにしようか・・・
（VerilogHDL側で修正が入ると、ファイル管理が面倒になるので、本当は一気にやっつけてしまったほうが簡単ではあるが）

面倒だったのは、VHDL-200Xでサポートされる機能がいつまでたってもFPGAベンダーのツールでサポートされないので、同じ関数を独自に定義しなくてはならない点である。

これは、定義すればいいだけなのだが、本来はパッケージとしてファイルの外部に出すべきところ、変換ツールという性格上、パッケージは作りにくい。
結果、関数をモジュール内部に定義して使うことにした。

verilogHDLからVHDLへの変換ツール

sfl2vlではVHDL出力の最適化はVerilogHDL出力ほどやっていない。というのも、VHDLの構文でVerilogHDL並みの最適化をするには、色々と信号を増やしたり、回避すべき問題が多く出力行数が今の1.5倍にはなりそうな感じだからというのと、（自動合成にさせるにせよ）VHDLで最適化された回路を書くのはとても面倒なのが理由である。

そこで、最適化されたVerilogHDLの出力結果を変換プログラムに食わせて最適化されたVHDLが得られれば、この面倒な作業を外部ツールに任せられるかも？と、二つのツールを試してみた。

一つは、CQ社のDWMで森脇氏が発表したツールV2Vである。

もう一つは、John Sheahan氏のv2vhdである。

で、結論から言うと、どちらのツールも機能不足であり、sfl2vlが最適化したコードは扱えなかった。

両者ともソースは公開されているが、森脇氏のはライセンス条件が不明なので、修正するとしたら、GPLが明示されているJohn Sheahan作のv2vhdだろうなぁ。

でも、これって、pearlで書かれていて、とても読みたい代物ではない・・・

sfl2vhの修正

O氏より、sfl2vhでVHDLに変換した結果に一部問題が発生し、うまく合成できないケースがあるとの情報をいただく。

問題点は2つである。

一つは外部端子の宣言をきちんと判定せず、内部的に保持している端子を誤って外部端子としてVHDLのentityに出力するケースがあり、不正な端子が余分に出力される場合があった。これは、外部端子の宣言であることをきちんと調査した上でentityの合成を行うように修正して対策。

もう一つはVHDLで算出演算を使うときの型変換のエラーである。私の使っているISE8.1iでは問題なく通る記述も、ISE8.1SP2では通らないらしい。
同じ環境がないと再現はできないのであるが、現象をじっと観察して、おそらく、型変換の演算オーバーライドがうまくいかないと判定。が、ISEのバージョンによって違うというのは困りものである。
結果、unsignedパッケージを新たにインポートすることで、オーバライドの状況をコンパイラに伝えることに成功。余分な型変換の呼び出しは抑止し、デフォルトの型で利用するように修正。

これで、VHDLの多くの合成系に対応できる・・・はずである。

MIX PowerC コンパイラ

MSDOS全盛の頃、MIXコンピュータのPowerCコンパイラが発売された。これは、$19.95という格安であるにもかかわらず、100ページ以上にも渡るANSI Cのチュートリアルと420個のライブラリ関数の全例題付きの数百ページの解説書として、その分かりやすい構成と文章に優れたものであった。

Windowsの時代になっても、Cの初心者向けには、このチュートリアルとライブラリの説明は充分役に立つし、（当然ながら、GUI部分はないが）今でも入手できるのかなと、検索してみたら、



まだ会社は健在のようでショッピングサイトから購入可能である。

が、$19.95のショッピングにUPS経由で送料が＄26かかり、何とも・・・

今日から、新しい人たちに職場にある本を使って、チュートリアルの読みあわせをしてもらっているが、いくつかのメリットがある。

・英語であるので、読み飛ばしをせずにきっちりとチュートリアルを読んでもらえる。
　　日本語の教科書を渡しても斜め読みして全部をまともに読んでもらえないものだが、英語だと斜め読みが出来ない人たちが多いので、ちゃんと読む訓練に良い

・英語の訓練になる
　　構文はかなり単純で癖もなく読みやすい本なので、英語が苦手な彼らにはちょうど良い英文読解訓練だ

・C言語の基本構文の解説がしっかり書かれている。
　　C言語の勉強用に読みあわせをさせているが、本来の（笑）目的にも優れた本である。

というように、この本（いや、本当はプログラムのマニュアルなのだが）にはかなり優れたところが多々あり、出来れば各自が自分で買って手元において欲しいくらいなのだが・・・送料さえかからなければとてもお買い得なんだけれどな・・

RDTSC命令

Pentium系のプロセッサにはタイムスタンプカウンタというカウンタがある。実は多くのアーキテクチャでこの手のカウンタはあるのだが、Pentium系のカウンタは64ビット幅なので、かなり時間が経ってもオーバフローすることが少なく使いやすいのである。

ちなみに、64ビットマシンのAlphaプロセッサでは設計者は何を思ったか32ビットのタイムスタンプカウンタにしてしまったので、長い時間の計測には全く使い物にならなかったのであった。

AMD64アーキテクチャにも当然ながらこのカウンタは継承されていて、命令の使い方は良く似ている。

が、64ビット値を読み出すというところで、32ビットマシンであるIA32とAMD64で高級言語からデータの読み出しをするときに注意が必要である。

64ビットの値を受け渡すのには、IA32ではEAX/EDXのペアでデータを渡すようにしているのであるが、64ビットアーキテクチャのAMD64が普通にC言語から64ビットデータを取得する時には、当然ながら1つのレジスタで読み出せるのである。

その部分が、トラブルの種になる。
RDTSC命令は、IA32との互換性を考えて、AMD64でもEAX/EDXペアにカウント値を読み出すので、64、32ビット共用の読み出し関数はこの点を考慮しないといけない。


inline long long rdtsc() {
int ax,dx;
asm("rdtsc":"=a"(ax),"=d"(dx));
return ((long long)dx<<32 | ax);
}

このカウンタ、実は利用時に注意が必要である。
というのは、単にクロック数をカウントしているだけのカウンタなので、ノートPCなどでSpeedStepをONにしていると、マシンの負荷状況によってクロック周波数が異なり、実時間に変換するときに、計測時点での実クロック周波数を読み出す手段がないと変換できないのである。

SpeedStepを用いていなければ何の問題もないのであるが・・

組み込みソフトウェア開発スタートアップ

CQ出版の組み込みソフトウェア開発スタートアップは、雑誌扱いだったので、AMAZONでは取り扱いがなかったのだが、先ほど来年のテキストの指定のため、CQ出版に見に行ったら、いつの間にやらムック扱いに変更になり、ISBNが付いていた。
ISBNがあればアマゾンで発注できるはずと検索してみたら、ちゃんと見つかるではないか。

組み込みソフトウェア開発スタートアップ


CQ出版さん、最初からムックで出してくれればよかったのにね～

ちなみに、この本、結構お勧めである。

sfl2vlの符号拡張とビット切り出し

SFLの言語規格では演算に対しても符号拡張やビット切り出しが可能となっているが、特に必要性を感じなかったので、sfl2vlではこれらは端子かレジスタに対してのみ許可していた。

ところが、昨日、ユーザから、「符号拡張をサポートしていないのですか」と質問があって、見たら演算結果を符号拡張しようとしていた。

ん～、エラーメッセージには識別子にしかこの演算はサポートされないって出ているだろうと思いながら、説明したが、演算結果を符号拡張するには、単に一時端子に代入するだけなので、言語処理系で行っても大したことはない。

ということで、処理系を少し変更し、20060211版からは、演算に対しても符号拡張やビット切り出しが可能になる。
注意が必要なのは、演算ビット幅が確定しない加算などの演算に対しては、望む結果と異なる出力が出ることがある点である。

これは、動作を考えれば当たり前の話で、これがあるから、確定したビット長の識別子にしか演算を許していなかったのであるが、気をつけて使ってくれれば処理系で自動にやった方が便利ではある。

一応、問題ないはずなので、リリースとしているが、何か問題があれば、連絡してもらいたい。

この機能は、たとえば、下記のような記述に利用するのである。

module exttest {
 input a<4>;
 input b<4>;
 output f<8>;
 output g<4>;

 par {
  f=8#(a+b);
  g=(a||b)<5:2>;
  }
}

グレイコードとバイナリコード

sfl2vlの状態遷移マシンの状態番号は宣言順にバイナリコードでアサインしている。
これは、教科書的にはNGである。スイッチング理論やディジタル回路の教科書では状態割り当てによって回路規模が大きく変わる「特殊ケース」が説明されることが多い。これらを受けて、バイナリコードアサインはあんまりだという人が時々いる。

実際問題として、大きな回路を作成するときに、教科書のような特殊ケースはまず発生することがなく、状態アサインの最適化の効果はほとんどゴミのようなものである。

これが、sfl2vlであえてバイナリアサインを保っていた理由なのだが、もう少し毛色の変わったアサインをしたい向きもあるだろうから、グレイコードアサインが出来るようにオプションを追加した。

sfl2vl filename.sfl -gray

と後ろに-grayをオプションとして付加することで、状態アサインはグレイコードになる。もちろん、状態変数の最適化なんてものは一切していないので、バイナリであろうとグレイであろうと出てくる回路は大差ないのである（そもそも、ALTERAのツールではどちらもFSM最適化によって無視され勝手に割り振りを付け直される）。
それでも、グレイコードにすることで、宣言順に順次状態が遷移する場合には多少回路的な負担が少なくなる合成系もあるだろう。