ＴＫ８０／ＢＳの
シンセシステムを復活／拡張したい〜
その２７
デジタルラダーフィルタの実験
２０１８年
９月３日
この週は遅い夏休みです。ガレージにアマゾンで購入したレベル変換基板が来ていました。早速、下ボードに実装しました。
アパートではアナログディスカバリから供給していたＳＰＩ−ＤＡＣの外部リファレンスの２．５Ｖを３．３Ｖ電源から供給するように修正しました。グレードＡのデバイスは電源と同じ電圧を外部リファレンスに入力できます。５００オームの抵抗を直列にして３．３Ｖと接続しました。８ｃｈ〜１ｃｈまで、０ｘ８０００〜０ｘ１０００のダミーデータ（直流）を出力しているので、ＤＡＣボードの１ｃｈのＬＥＤ１と２ｃｈのＬＥＤ２が消灯し、動作良好です。
下ボードにＭＣ８０＋バスを配線しました。ＴＫ８０／ＭＳＰ４３０からの５Ｖ系データの８ビット、アドレスの４ビットをレベル変換ボードを介してＦＰＡＧに接続します。
ＦＰＧＡの論理を変更して、ＳＰＩ−ＤＡＣの入力を直流のダミーデータから、ＤＤＳに変更します。全ＬＥＤが中輝度で高速点滅しています。アナログディスカバリで出力を確認しました。動作良好です。
９月４日
左はＳＰＩ−ＤＡＣの入力をＤＤＳに修正したシフトレジスタ部のソースコードです。ＤＤＳの出力は基本周波数の矩形波なので、１６ビットあるＤＡＣの入力の１５ビット目に接続しました。リファレンスが３．３Ｖなので、ＤＡＣの出力は約０．８２５Ｖの矩形波になります。右はアナログディスカバリで確認したＤＡＣの出力波形です。ＤＤＳ出力とサンプリングの４８ＫＨｚは非同期なので４８ＫＨｚの幅でジッタが発生します。矩形波なので目立ちますが、これは普通にアナログ信号を４８ＫＨｚでサンプリングしているのと同じなので問題ありません。
ＭＣ８０＋バスに接続して音出してみました。ＤＣＯの代わりに４ｃｈ分のみシンセに接続します。バスのラッチ、ＤＤＳ部は実績がある回路なので、そのまま動作しました。ＭＰ３ファイルはこれです。
以前にＰＣで普通に作成した浮動小数点版のラダーフィルタのプログラム（大元はこれ）を固定小数点に変更して動作確認します。固定小数点をｌｏｎｇ（６４ビット）に割付て小数点部を下位の１６ビットに設定しました。左が浮動小数点、右が固定小数点版です。カットオフ１０ＫＨｚ、フィードバック２．０です。
同じく、左が浮動小数点版、右が固定小数点版です。カットオフ２ＫＨｚ、フィードバック３．０です。浮動小数点版も固定小数点版もほぼ同じ波形出力で問題なさそうです。
９月５日
ラダーフィルタをＶｉｖａｄｏのＨＬＳで実装できるか確認します。まずは、ＨＬＳの勉強をします。ＦＰＧＡ大全の１０章を見ながら一通りやってみました。左は配列同士を１６回掛け算して終了する、簡単なサンプルコードです。右は合成すると動作速度とロジック使用量のレポートが得られます。全体のフローは分かりましたが、どうやって４８ＫＨｚサンプリングに合わせればいいのかなどタイミング制御方法はまだ不明です。
９月６日
固定小数点版のラダーフィルタをテストベンチとフィルタ本体に分割し、ＨＬＳのプロジェクトとして作成します。コンパイル時にテストベンチの入力のダミーデータをｌｏｎｇで定義している所のサイズが合っていないというワーニングが出ます。
ＨＬＳのｉｎｔ、ｌｏｎｇ、ｌｏｎｇ ｌｏｎｇのサイズを確認していみます。４、４、８バイトです。
ＰＣのｃｙｇｗｉｎのｇｃｃのｉｎｔ、ｌｏｎｇ、ｌｏｎｇ ｌｏｎｇのサイズを確認していみます。４、８、８バイトです。ｇｃｃのｌｏｎｇは８バイトですが、ＨＬＳのｌｏｎｇは４バイトでした。上記のワーニングの原因が分かりました。
ＨＬＳのソースコードのｌｏｎｇを全てｌｏｎｇ ｌｏｎｇに変更しました。ワーニングが無くなりました。続いてＨＬＳで合成を行い、レンテンシとロジック使用量を確認します。動作速度は１００ＭＨｚ以上でも動作します。レイテンシは２３クロック、データも２３クロック毎に入力可能です。今回は音声帯域の４８ＫＨｚのサンプリングなので、速度的には全く問題無さそうです。リソースですが、ＡＲＴＹボードのＸＣ７Ａ３５は乗算器（ＤＳＰ４８Ｅ）が９０個しかないのですが、１９２個使っているというレポートが出ています。これはどのように対応すればいいのか〜もう少し調査が必要です。
９月７日
ラダーフィルタのコードは１次ＬＰＦの関数を別々に作り、４個直列に接続しています。各係数も同じで、同じ動作をしますが、処理後の出力結果を後で使う必要があるため、別関数になっています。これが原因で乗算器の使用量が多くなっているのではと思い、これを１つにしてみます。
上位の関数でＬＰＦの出力結果を個別に用意し、ＬＰＦ本体を１つにします。コンパイル、シミュレーション続いてＨＬＳで合成を行い、ロジック使用量を確認します。以前は１９２個だったものが２０８個に増えていました。これは失敗でした。
９月８日
ＷＥＢページやユーザガイドなどを調べると、ＶｉｖａｄｏのＨＬＳはデフォルトで速度重視で合成されることが判明しました。今回のラダーフィルタの動作クロックをＳＰＩ−ＤＡＣと同じ１５．３６ＭＨｚにした場合でも、３２０クロック内に収まっていれば４８ＫＨｚのＳＰＩ−ＤＡＣのロードに間に合います。ＨＬＳの合成には色々な最適化指示が用意されています。指示は速度を早くするものが多いのですが、今回は動作速度を落として、リソースの使用量を減らす必要があります。このページが参考になります。使用する関数の数の制限するＡＬＬＯＣＡＴＩＯＮという指示があり、ｍｕｌｔ_ｆ関数を１つに制限してみます。これを４つのＬＰＦのブロックの先頭に入れてみます。
コンパイル、シミュレーション後に合成を行い、レンテンシとロジック使用量を確認します。動作速度は以前と同じ１００ＭＨｚ以上、レイテンシは７３〜８０クロック、データも７４〜８０クロック毎に入力可能です。レイテンシは３倍以上になりましたが、乗算器（ＤＳＰ４８Ｅ）の使用量は劇的に減って１９２個から１６個になりました。１０分の１以下になりましたが、仮に別のモジュールで乗算器を使わなくても、現状では８ｃｈ分は入らないことになります。
テストに使ったのは昨日と同じカットオフ１０ＫＨｚ、フィードバック２．０の１サイクル分です。シミュレーション時にコンソールに出力されたログから波形を作成しました。
Ｃ／ＲＴＬ協調シミュレーションを行うと、波形でタイミングを確認できます。テストベンチで設定している入力データの＋１が３２個、−１も３２個分入力されています。
ラダーフィルタの出力結果の戻り値はａｐ_ｃｔｒｌ_ｈｓというハンドシェイク信号で確認できます。ａｐ_ｄｏｎｅは終了です。この信号の間隔は８１０ｎｓｅｃになっています。クロックは１００ＭＨｚなので、８０クロックに相当します。レポートのレイテンシと一致します。
肝心の戻り値を確認してみます。先頭は１０３８で、２番目は３８３０です。上位の整数部は０なので、少数点以下の値と分かります。
元のＣの固定少数点版のプログラムに１６進の出力を追加して比較します。１０３８と３８３０で合っています。ＣとＣをＨＬＳでＲＴＬに変換したロジックの結果が同じになることを確認しました。まあ、そのように作られているので、当たり前なのですが、よく出来ています（笑）。現状では７４〜８０クロックの最速で動作してしまうので、クロックを１５．３６ＭＨｚに設定し、ＳＰＩ−ＤＡＣのサンプリング周波数４８ＫＨｚ毎に計算させる必要があります。当面の目標はＤＤＳの任意周波数の矩形波を入力し、ＳＰＩ−ＤＡＣに出力することです。
９月９日
出力結果を外部信号に同期させて遅延させるａｐ_ｃｔｒｌ_ｃｈａｉｎというインターフェースがあります。下はザイリンクスのＨＬＳユーザガイドｕｇ９０２のタイミング図です。ａｐ_ｃｔｒｌ_ｃｈａｉｎを選択するとａｐ_ｃｏｎｔｉｎｕｅという信号が増えて、ａｐ_ｄｏｎｅがｈｉｇｈの時に、この信号がｈｉｇｈでなければ終了が遅延されと書いてあります。
早速、最適化指示を追加してみます。Ｃ／ＲＴＬ協調シミュレーションを行いタイミングを確認します。ａｐ_ｃｏｎｔｉｎｕｅはテストベンチで動作するようにａｐ_ｄｏｎｅと同じタイミングでｈｉｇｈになっています。実際にはラダーフィルタ部をＩＰ化して外部からこのａｐ_ｃｏｎｔｉｎｕｅ信号を制御すれば、４８ＫＨｚサンプリングに合わせることができそうです。
９月１０日
ａｐ_ｃｏｎｔｉｎｕｅ信号はＳＰＩ−ＤＡＣのＬＯＡＤ信号で良さそうです。７４〜８０クロックでａｐ_ｄｏｎｅ信号ｈｉｇｈになり、３２０クロックでａｐ_ｃｏｎｔｉｎｕｅ信号がｈｉｇｈになるまでａｐ_ｄｏｎｅとラダーフィルタからの戻り値（ＲＥＴＵＲＮ）が引き伸ばされ、ＬＯＡＤ信号がｈｉｇｈの時に次段のモジュールにロードします。
実験するブロック図です。ＤＤＳ−ＤＣＯ（方形波出力）とＳＰＩ−ＤＡＣは実装済みです。この間にデータ保持ＦＦとラダーフィルタを実装します。
