DSP空挺団

STM32F746の信号処理性能

いろいろ問題がありましたが、Nucleo F746ZG用のUI基板『浮舟』が完成しました。浮舟には性能測定用のテストポイントを付けましたのでオシロスコープの接続が容易です。ということで、ようやく肝心の性能評価にかかりました。

結論から書くと、十分な性能がでています。

三角関数

stdlibのsin()関数の実行です。

sin()関数の1回の実行が1.16uSです。これは割り込み処理等のフレームワーク・オーバーヘッドを含みます。一方、ブロックサイズ=11とした11回の実行は同じくオーバーヘッド込みで8.81uSです。ですので、1回の実行時間は0.76uSです。

サンプル周期は20uSです。もくろんでいるアルゴリズムは、この間に4回程度sin/cosを実行することになると思われます。その時間が3uSなら、許容範囲です。archtan()についても調べましたが、同程度の計算時間です。

FIRフィルタ

CMSISのarm_fir_f32()を使って100タップの浮動小数点FIR関数を実行しました。ブロックサイズ=1のときは割り込みオーバーヘッド込みで4.2uS。ブロックサイズ=11の時は同じく17.9uSです。このことから1000タップの実行時間は13.7uS、1タップの平均は13.7nSとなります。

処理速度としては申し分ありません。おおよそ200MHzでこの性能と言うことは、タップあたり3サイクルを切っており、汎用CPUによる信号処理としては文句の付けようがない性能です。

まとめ

「Fs=48kHzで1サンプルの間にsinとcosを計4回、128タップのフィルタを4本回せると良いな」と、考えていましたが、充分以上の性能でした。この処理ならSTM32F746を200MHzで動作させて、だいたい50%くらいの処理負荷になりそうです。

Nucleo F746ZG用UI基板

明けましておめでとうございます。

この正月は、昨年12月にはいってから作業していたNucleo F746ZG用UI基板『浮舟』のテストをしていました。

このボードはNucleo F746ZG用コーデック・アダプタ『桐壺』とペアで使うことを想定した基板で、組み合わせて使うことで、Nucleo F746ZGの浮動小数点演算能力をどの程度オーディオ信号処理に使えるか実験したいという目録見です。

昨年末は忙しかったため、ようやく年末になって組み立てに着手出来たのですが、さて結果はと言うとぼろぼろです。問題点を列挙すると以下のようになります。

• ボリューム読み取りようのI2C3, I2C4のプルアップ抵抗を忘れていた
• GPIOがmbedのUSB シリアル・ポートとかぶっている
• GPIOがARMのデバッグ・ポートとかぶっている
• 集合抵抗や集合コンデンサは思いの外、入手性が悪い

特にUSBシリアル・ポートとのかぶりは問題です。低価格評価基板と言うことで甘く見ていましたが、Nucleo F746ZGには多数のショート・ブリッジが実装されており、ピンをGPIOに振るか、EthernetやUSBのような高機能IFに振るかを選択できます。今回、EthernetやUSBは使いませんが、USBシリアル･ポートはmbedの重要なデバッグ手段ですので看過できません。

結局、部品の変更やシルクの不満点などの修正点と併せてレイアウトを変更し、ver2として新年のうちに作り上げました。今日、ガーバーをスイッチサイエンスに送りました。早くすれば1月中旬のうちに新しい基板がくるでしょう。中国の正月とぶつかることは避けたいものです。

InterpolatorとDecimatorの制約

オーディオ用のInterpolatorとDecimatorはFIRフィルタの変形として実装することが多いですが、一般には係数長やブロックサイズ長に制約があることは知られていません。

何故知られていないかというと、あはは使われないからです。あはは。サンプル周波数を変える等というのは、なかなかアマチュアのフィールドには降りてきません。そんなものを使う場合にはエキスパートなわけで、エキスパートはエキスパートのコミュニティを持っているから一般には知る必要も無いと言うことでしょう。

実際にどんな制約があるか、CMSISのDSPライブラリを見てみましょう。たとえば、arm_fir_decimate_init_f32()の返り値に関する記述を読んでみると以下の記述があります。

The function returns ARM_MATH_SUCCESS if initialization was successful or ARM_MATH_LENGTH_ERROR if blockSize is not a multiple of M.

多少記述が曖昧ですが、blockSizeはダウンサンプル比Mの整数倍でなければなりません。明示されてはいませんが、同じ制約がarm_fir_decimate_f32()にもあるはずです。

また、arm_fir_interpolate_init_f32()には以下の記述があります。

The function returns ARM_MATH_SUCCESS if initialization was successful or ARM_MATH_LENGTH_ERROR if the filter length numTaps is not a multiple of the interpolation factor L.

係数長はアップサンプル比Lの整数倍でなければなりません。

自分で実装するとこれらの制約は自明なものとして頭に入るのですが、使うときにはちょっとした罠になるため注意が必要です。

OneDriveとOneDrive for Businessはembedの方式が違う

昨日、signalbottom関連のデータアップロードに手間取ってしまいました。原因はOneDriveとOneDrive for Businessの違いです。

WordPressには外部サイトからのembedデータを埋め込む機能があり、スライド埋め込み用としてずっと利用しています。ところが、今回急に使えなくなりました。理由は私がデータをOneDriveからOneDrive for businessに動かしたことです。両者はembedデータのexport形式が異なり、OneDrive for businessのデータをwordpressに埋め込むことはできないのでした。

いろいろとあしを取られる事が多いです。

C言語のfloatとdouble

昨日書いたエントリは、少し混乱気味でした。

話の内容としては「バグを取り除いた」「しかしまだ比較的大きめな雑音が残っている」と言う二つの話なのですが、書き方が悪くて「バグを取った、それが雑音の元だった」と言う文章に読めてしまいます。ちょっと書き直していますので、昨日読んだ方は読み直していただければと思います。

さて、バグ取りの内容ですが、「評価プログラムの浮動小数点型がfloatだったのでdoubleに直した」というものです。

実装したCORDICは32bit固定小数点数です（精密に言えばQ2.30フォーマット）。したがって、制度調査をする場合、基準となる浮動小数点sine関数は、倍精度浮動小数点にする必要があります。単精度浮動小数点数は、隠しビットを含めても仮数部が24ビットしかないからです。

ということで当然倍精度浮動小数点型を使わなければならないのですが、それがわかっていてfloatを使っていたというのがバグです。つまり、私のC++言語に対する理解の誤りが根本原因でした。

私はC言語の知識が古いので、K&Rの「float型はコンパイル時にdoubleに昇格される」という知識が頭にこびりついています。C言語のANSI標準制定時にこのルールは改正され、floatはfloatとして扱われる事になっています。それは頭にたたき込んだ覚えがあるのですが、いつの間にやら溶けて消えたようです。

私の場合、経歴の長い部分をDSP屋として過ごしています。「このプロセッサではfloatは32bit。しかしそれはDSPだから」という誤った先入観念が邪魔をして「x86ではfloatは32bit、あくまで32bit」という事が頭に定着するのを阻害していたのだと思います。

言い訳でしか有りません。正しい知識無くしては、プログラムは正しく動作しないと言う当たり前のことです。

精度評価進行中

土曜日にSignalbottomの呑み会がありました。今回も大変刺激的なプレゼンを聞くことができ、励みになりました。みなさん、ありがとうございます。

さて、VHDLで書いたSinCosのCORDICですが、再度評価プログラムのバグが見つかり、かなり大きいとため息をついていた誤差がぐっと小さくなりました。

一方で、まだ結構大きめな雑音があります。CORDICは1ステージ増やす度に1bit誤差が小さくなるアルゴリズムなのですが、一方でLSBから累積されていく丸め誤差の総和は増えていきます。ここは理屈の上では1ステージあたり0.5LSBの誤差なのですが、実際にはシフト部での丸めとあらかじめ計算している進角の持つ0.5LSBの誤差が両方効いてきます。N回誤差の蓄積は一般に√N倍になるわけですが、統計的に見てみれば、N倍のピークがあっても不思議ではありません。

あらかじめ必要なビット精度を定めた後、丸めで汚染されるビットを切り捨てるために事前シミュレーションが必要なようです。

精度はもう少し評価してみます。

SinCos CORDIC精度評価開始

VHDLで設計したSinCos CORDICの精度評価を開始しました。

実際には、精度評価をするのはVHDLによる設計ではなくC++によるモデルの方です。両者はビット単位で合致するようチェックをかけていますので、それを担保にC++でテストをします。C++の方が親しんでいる分、テストプログラムを書きやすいです。

で、昨日は初っぱなから躓きました。妙な誤差があります。0と±πではほとんど誤差がないのに、その間では盛り上がるように誤差が増えていきます。誤差の絶対値としては126dBくらいです。一見、十分低いようですが32bit精度でこれでは困ります。熟考後、当たりを付けたのがπ精度。テストプログラムではエイヤ！と3.141592を使っていたのですが、これが原因でした。精度を倍精度浮動小数点数に合わせると、平均で30dBくらい改善したようです。ちょっと盛りすぎか。

ピークにはまだ不満があるので、腰を据えて追いかけていきます。

int32_t

32bit幅を仮定する整数をint32_tに変更しました。

「ポータブルにしよう」としたのはいいのですが、標準でビット幅保証の型が存在しているとは知りませんでした。不勉強です。

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リポジトリにコミットしながら作っているのですが、そろそろタグを打って精度検証にうつってもいいかなと思っています。