32bit整数
C++のint型を32bitと仮定することに漠然と不安を感じます。
用途がVHDLのモデル記述である以上、プラットホームはx86/AMD64上のUbuntuになります。大きく見積もってWindowsが加わるくらいですが、この範疇だとgccのintのサイズは32bitです。ですからそれほど心配する必要はありません。
が、やはり不安を感じます。vhdlint32みたいな型をtypedefで作った方がいいんでしょうね。
だいぶ落ち着いてきた
VHDLによるCORDICの実装は、だいぶ落ち着いてきました。
当初VHDLの習得をかねて初めたCORDICの実装ですが、現状では以下のような感じです。
- 32bit幅までの構成可能なワード幅
- 32段までの構成可能なワード幅
- C++モデル
- スクリプトによるモデルとシミュレーション結果のつきあわせ
- DoxygenによるC++/VHDLコメント
盛りだくさんですね。個人用のgitリポジトリにコミットしながら作っているのですが、そろそろタグを打って精度検証にうつってもいいかなと思っています。
PythonでVHDLテスト用の動作モデルを作ることの検討
先日すこしツイッターで呟きましたが、C言語というのはどうも余計な記述が多すぎる気がします。
{}を閉じるとかそういうことならともかく、クラスの宣言を丸々ヘッダファイルに持つなど、いくら分割コンパイルが切実な時代の設計とは言え、ちょっとやり過ぎに思えます。一方、コードに対する記述量の少なさならPython、ということで試してみました。
そして結論から書けば、私の場合Pythonで今後VHDLテスト用の動作モデルを書かないという結論に至りました。
一番大きな理由は、整数型の抽象度が高すぎて固定ビット長のビット列として扱うことに無理があることです。Pythonにおける整数には値の上下限がありません。必要に応じて適宜必要なビット数が整数オブジェクトに割り当てられます。この方法は通常のユーザーには便利ですが、固定長ビット列でのデータ操作を必要とする組み込みには決して相性が良くありません。特に符号付き2の補数表現は、ビット数が固定である事に依存していると言っても過言ではなく、そのビット数が場所によって変るディジタル回路設計は、ビット数が「値によって変る」というPythonとはかみ合わせが悪いのも仕方ありません。
そういうわけで、今後もモデル作成はC++にする予定です。
GNU LDのライブラリ・リンクの順番
GNU LDのライブラリをリンクする順番で半日もがきつづけていました。
以下はLD呼び出し時のスクリーンショットですが、黄色で示した二つのライブラリ指定オプションの順序をひっくり返すと、リンクに失敗します。
そのときのエラーメッセージが以下の通り。
`vhdl::local_numeric_tools::sra_round(int, int)’ に対する定義されていない参照です
これはわあからない。C++の関数の引数の型指定が甘くて多重定義された別の関数を探しているのかと思って、無駄にプログラムを精査しましたよ。
この点について、LDのマニュアルには以下のように記されています。
The linker will search an archive only once, at the location where it is specified on the command line. If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive. However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again.
つまり、「（リンカーが注目している）ライブラリの中で定義されているシンボルが、そのライブラリより先に現れたファイルの中で未定義シンボルとして参照されている」ならば、（注目している）ライブラリのその定義を取り出して、出力する。というわけです。
最初のスクリーンショットに関して見てみると、確かにlibcordic_sincos_model.aのなかで、sra_round(int, int)が未定義シンボルとして参照されています。そして、そのシンボルはlibpackage_model.aで定義されています。
このような順番の制限は１パス・リンカ故のものです。
GNU LDともなるとリンク対象はGCC C++コンパイラやLinuxカーネルのような巨大なものまでが対象になります。それゆえ2パスのような時間のかかることを避けたかったのだと思いますが、コマンドライン・オプションとてユーザー･インターフェースなのですから、もう少し富豪的に2パスでもいいやん、と思うところです。
工夫
VHDLの個人用パッケージとそのテスト・スイートを作りました。
テストしていると「こうするともっと汎用的になる」「こうするともっと便利になる」とアイデアが浮かんできます。ただ、それが本当に必要な工夫なのかは別の話なんですよね。一生工夫してろ！って自分に言いたくなるくらい、工夫ばかりで先に進まないことがあります。
VHDLのコンパイルにmakeを使う方法を思いつきましたが、これは導入をあきらめました。綺麗ではあるけれど、工数が多すぎ、みのりがないように思えます。
一方で、テスト・スイートのC++モデルの再利用については、手を動かして実装するつもりです。
理想の環境はTSSだった？
最近VHDLによる開発を勉強する環境について考えています。
現在は、VMwareによるLinux環境をあちこちに仕込み、渡り歩いて使っています。例えば、自宅のデスクトップ、自宅のラップトップ、持ち歩き用のUSBメモリ等です。何処に行ってもgitで同期をとればいいのでその点は便利ですが、一方でやはり重いとも感じます。なにしろ、C++モデル編集→ベクター生成→VHDl編集→試験、と言う流れはテキスト処理で完結しています。極端なことを言うと、このサイクルではGUIは不要です。
と、言うことはです、TSSでもいいんですよね。AWSの継続インスタンスにLinuxを仕込んでおいて、必要に応じてsshでアクセスすればいいのです。なんてことでしょう。いまさらTSSを再認識する日が来るとは。
もう一箇所修正したい
VHDLで書いているCORDICですが、あと一箇所修正したいところがあります。
現在CORDICアルゴリズムの精度に影響する段数に関してはgenericとして指定できるようになっています。一方、直接の演算精度であるbit幅についてはサブ・モジュールでは対応しているもののCORDICアルゴリズム全体としては対応していません。ここを拡張したいところです。
VHDLによる設計とC++によるモデルの双方が修正が必要なので少しまとまった時間が欲しいところです。一方で、リファクタリングを隙間時間でがんがん出来たのは、gitを使った渡り歩きとモデルを使った毎回のテストのおかげです。
モデルによるテストは楽ですわぁ。
すべてが盆栽になる
VHDLのコードを整えています。
開発時に書き込んだデバッグ用の覚え書きなどを消しつつ、コメントを意味のある物に変更。変数名もあとから見直すとへんてこな物がありますのでこれを変更。
もうちょっと整えたいところもあります。
コメント形式のテスト
ちょっと考えることがあって、コメント形式をいじってみました。テスト･ベクター生成プログラムです。
もともと、コメントは各行の右に書いていました。
こうしてみると、上に書いた方が遙かに合理的ですね。まぁ、わかりきったことではあります。次からはこの手のコードは上にコメントを書くことにします。
リファクタリング、リファクタリング、リファクタリング
VHDLによるCORDICは、精度検証そっちのけで書き換えを続けています。リファクタリングを越えてインターフェースや階層構造、果ては根幹にかかわる構造まで書き換えていますので、全面刷新に近いです。
普通はこれだけ大規模な書き換えには躊躇するのですが、VHDLによる設計とC++によるモデルの実行結果を付き合わせて可視化するスクリプトを書いて常走らせているため、間違いを発見しやすく個々の作業に対する安心感があります。
よくわからないままに書いていたVHDLも度重なる書き換えを経て我がコードながら洗練されたものになり、勢いで書いていたC++モデルやテストベクター生成コードも全部クラス化しました。
CORDICアルゴリズムの引数の値域も拡張し、今はひたすらDoxygenコメントを書いています。仕事じゃないので時間制約もなく、楽しいです。