電子回路わからん日記

にゃーんと言いながら電子回路いじってます

libsndfileのサンプル集、作りました

プログラミング

どもです。

表題の通り、libsndfileの関数を使ってオーディオファイルをいろいろ操作するサンプル集「libsndfile-samples」をリリースしました。

github.com

背景

趣味柄FPGAデザインにI2Sを流すことがあるんですが、1kHz正弦波だったり、インパルスだったり、「左だけ1kHzで右は無音」みたいな「欲しいときに欲しい音源を生成したい」ということは多々あります。

Pythonでも手軽にこれらのファイルを生成できるライブラリがあるのですが、

github.com

Pythonだとデータ量に比例して極端に実行時間は遅くなりますし、MATLABは有料ですし、かといってOctaveをこのために勉強するのもなんですし、「高速にかつ無料でAUDIYにとってコストなく」生成しようとするとやはりC言語に戻ってしまいます。

過去にAUDIYはWAVIOという、WAVファイル限定の読み込み・書き込みライブラリを作っていましたが、

github.com

これはWAVファイルの構造を理解する目的で作っていたものであり、FLACファイルなどに対する対応ができないため柔軟性がありませんでした。

ということで、この際なのでlibsndfileを使ってオーディオファイルを読み書きできるようにしておこうという魂胆です。

libsndfileについて

幅広いオーディオファイルやデータ形式（short, int, float, double）に対応しており、柔軟性高くオーディオファイルを読み書きできます。

libsndfile.github.io

WAV, AIFF, FLAC、なんとMATファイルにも対応しています。

これは使わない手はありません。

実はこのlibsndfile

libsndfile自体、複数のexampleを持っています。

github.com

ファイルをコピーしたり、各チャンネルの音量を調整したり、テキストファイルに出力したりといろいろありますが、Programming Interfaceに記載の関数の実際の動作を網羅しているようなものではありません。

libsndfile.github.io

今回は「一つ一つの関数の動作をたしかめる」ことを目的にサンプル集を作ってみました。

構成

2025年2月22日時点で30個のサンプルから成り立ちます。

github.com

各関数を確認してて便利だなと思ったのは「浮動小数（double）から整数型のファイルを生成できる点」や、wavファイルに任意のチャンクを埋め込むことができる点です。

 

 

上記ツイートはlibsndfileを使ってwavファイルの中に"Test"というチャンクを作成し、"The quick brown fox jumped over the lazy dogs."という文字列データを埋め込んだ例です。

一部使用できるオーディオファイルも6つほど保存してあります。

github.com

興味のあるかたはぜひいろいろ試してみていただければと思います。

 

また、Issues、Pull requests、Star、Folk大歓迎です。

タイミング制約でどこまで遅延調整が働くのか試してみた

FPGA 日記

どうもです。

突然ですが皆さん、FPGAと周辺デバイスで通信するとき、クロックとデータの関係ってどうなってます？

AUDIYはI2CとかSPIのイメージで「クロックの1→0への変化に合わせてデータも変化する」というイメージがあるのですが、肝心のFPGAはそういった通信をクロックの「立ち上がり」でデータを読み取るので、FPGAから出力するときにどうすればいいか迷った時期がありました。

実際に過去に質問したことがあるのですが、

当時は知識がなく上記の選択肢くらいしか思いつきませんでしたが、その中で出てきた返答が

当初は「シングルエンドなのにDDR？」と思いながら調べたところ、なんと「2つのデータ入力に0と1を入力しておいて、実際のクロックと逆位相を出力する」というもの。

AMDでも紹介があるので、ごくごく一般的な方法なのだと思います。

docs.amd.com

ちなみに上記のような「データウィンドウの中心にクロックの読み取りエッジが来る」信号を「センターアライン」と呼ぶそうです。

monoist.itmedia.co.jp

その一方・・・

下記記事ではDDR出力を利用せずに、センターアラインの通信においてクロックの読み取りエッジ付近でセットアップ/ホールドを制約する方法が記載されています。

monoist.itmedia.co.jp

この記事の書いていることが本当であれば「逆位相のクロックを作らなくてもセンターアラインの通信において制約を満たす設計が可能な場合もある」ということになります。

と同時に、AUDIYの中で一種の疑問が湧きます。

「どの程度までなら遅延を加えることが可能なんだ？」

実際にタイミング制約をいじって複数のFPGAデバイスで確認してみることにします。

実験に用いたデザイン

なんてことはない、8bitのアップカウンタです。

8bitアップカウンタ

FPGAボード上の水晶発振器からのクロックをPLLで分周し、PLL出力の立ち上がりエッジに同期して数値を1ずつ増加させていきます。

PLL出力の周波数は使用するオシロスコープ（Analog Discovery 3）の性能も考慮して2MHzとし、出力クロックの立ち上がりエッジとカウンタ出力の最下位ビット（実質出力クロックの2分周）との時間差を計測します。

時間差を確認しながらタイミング制約のset_output_delayの値をいろいろいじってみて、実際に遅延を付加できるのか、付加できる遅延量の最大値はどの程度なのか確認してみます。

タイミング制約

以下、出力遅延に関するタイミング制約です。

set_output_delay -clock { o_clk } -min -15.000 [get_ports {o_count[0] o_count[1] o_count[2] o_count[3] o_count[4] o_count[5] o_count[6] o_count[7]}]
set_output_delay -clock { o_clk } -max   5.000 [get_ports {o_count[0] o_count[1] o_count[2] o_count[3] o_count[4] o_count[5] o_count[6] o_count[7]}]

クロックの立ち上がりエッジに同期してカウントアップすることを考えると、センターアラインと仮定したときにカウンタの出力を受けるデバイスにとってシビアになるのは「ホールドタイム」になります。

以下記事に記載の内容の通りに捉えるとホールドタイムに関する制約は-minの数値で規定できるので、今回は配置配線結果をなるべく揃えると言う意味でも-maxの値は5nsで維持しておき、-minの値を0nsから負の方向にシフトさせていきたいと思います。

monoist.itmedia.co.jp

DE0-Nano (Altera Cyclone IV E EP4CE22F17C6N)での確認結果

ホールドタイム0ns

Ch1がクロック、Ch2がデータになります。

実遅延時間は389.1psです。

ホールドタイム5ns

実遅延時間は6.926nsでした。

ホールドタイム10ns

実遅延時間14.55nsでした。

ホールドタイム15ns

実遅延時間23.27nsでした。

入力した制約値に応じてデータが遅延していることがわかります。
また、制約の値を-16nsにした時点でタイミング制約違反が発生しました。

 

別デバイスでも同様に確認してみます。

Efinix Trion T20 BGA256 Development Kit (T20F256I4)での確認結果

だめです。まったく変化しません。時間を広げれば広げるだけその差分がタイミング制約違反となって現れます。DE0-Nanoのように「ある程度遅延が付加される」ということはありませんでした・・・。

よくよく考えると・・・

というか当たり前のことなんですが、タイミング制約って遅延調整をするためのものではなくて、あくまで「設計したデザインが周辺デバイスのセットアップ/ホールドを満たせるか」を確認するツールなので、Alteraみたく「ある程度調整してくれる」とは限らないんですよね。

ということは下記の記事は「センターアラインのソースシンクロナスでもたまたまセットアップ/ホールドを満たせたらそのデザインを使えますよ」と言っているだけに過ぎません。

monoist.itmedia.co.jp

個人的には「こんな危ない橋をわたるくらいならハードウェアリソースを活用してDDRで反転出力するかな」と思いました。

malt.zendesk.com

それにしてもAltera FPGAはやはり柔軟性が高いですね。
今回AMDは手持ちのFPGAのMMCM/PLLで2MHz出力できなかったのでスキップしましたが、どこまでの柔軟性があるか試してみたいです。

 

KRIA KR260でDDS + FIRをやってみた

AMD FPGA KRIA KR260 日記

どうもです。

最近はGitHubを積極的に稼働させています。

github.com

 

久々にFIR_x2にも手を入れて、

  • Altera （旧Intel）
  • Efinix
  • Gowin
  • AMD（旧Xilinx）

の4環境で試せるようにしました。

audio-diy.hatenablog.com

 

三日坊主にならぬよう頑張ります。

コードレビュー、プルリク、フォーク、favorite、アカウントフォロー大歓迎でございます。

「KR260でデジタル信号処理」

本題に入りたいと思います。

読者の多くはご存知かと思いますが、AUDIYはFPGAにデジタルオーディオ信号処理を実装するのが趣味です。

 

そんなAUDIYにとって見逃せないチュートリアルがありました。

https://www.avnet.com/wps/portal/japan/manufacturers/amd/blog/try-to-digital-signal-processing-with-kr260-1/

https://www.avnet.com/wps/portal/japan/manufacturers/amd/blog/try-to-digital-signal-processing-with-kr260-2/

https://www.avnet.com/wps/portal/japan/manufacturers/amd/blog/try-to-digital-signal-processing-with-kr260-3/

 

KR260のPL内部にてDDS（Direct Digital Synthesizer） IPとFIR IPを組み合わせてFIRフィルタを動作させて、所望の帯域でフィルタ（ローパス/ハイパス/バンドパス）がかかっていることをILAで確認するというものです。

もともとは以下リンク先で紹介されてたKD240でのチュートリアルをKR260に対し行ったもののようです。

www.hackster.io

 

以下YoutubeにてAMDが公式でチュートリアル動画も出しています。

 

ということで実際にやってみましたがいくつか嵌まった点があるので、ここに共有したいと思います。

 

事前に上記記事や動画を御覧いただいたうえで記事を読んでいただくと詳細がわかりやすいかと思います。

ILAが・・・・出ない！

さて、上記の動画の通りにVivadoでIPどうしを配線して、VitisでHello Worldをビルドして、Debug実行したところ・・・・

 

・・・・ILAが・・・・出ません！

ILAが表示されないだけでなく、Hardware Managerからdbg_hubが見えないという有り様です。

 

なお、配置配線結果（Implemented Design）上にはいるのでもう何がなんだか理由がわからず、とりあえずAMDのCommunityに状況を投げるのでした。

adaptivesupport.amd.com

psu_init...?

やはり持つべきものは強い先輩です。

調べたところ、

adaptivesupport.amd.com

どうやらPS部の初期化スクリプトのようです。

また、似たような（というかほぼ同じ）問題にあたった人も過去にいたようで、

上記ツイートの返信のやり取りを見ているとどうも同じ問題に見えます。

とりあえずやってみる

アドバイス頂きながらやってみました。

設定を見直したところ、場合によってエラーになることもありましたが、実行が開始された場合・・・

ILAが見たことの無い波形でお手上げ状態でした。

実は・・・

 

これ、実は動いてました

 

動いていることはわかったのであとは必要な波形を取捨選択すればよいのですが、

 

ウィンドウ長をデフォルトの1024のまま実行すると実際にFIRフィルタが効いているかがわかるか微妙です。

これを4096とか8192とかにして・・・・

 

なるほどここまできて初めて所望の波形を観測できるんですね。

ということで、チュートリアル外で必要だった作業は以下3つになります。

  1. ソフトウェア実行時の初期化モードを見直す（psu_initを有効にする）。
  2. 自動で表示される波形から実際に見たい必要な波形を取り出す。
  3. ILAのウィンドウ長を長くとる。

最後に一言。

以上です。

 

ひっちゃかめっちゃかしすぎなKRIAの情報サイトまとめ

AMD FPGA KRIA KR260 Qiita HDL Advent Calender 2024

どうもです。

空気を読まずにアドカレ最終日を確保する（らしい）AUDIYです。

ということで、ゆるーくまとめていきたいと思います。

「KRIA、何からどう始めれば良いの？」

KRIA（正確にはその開発キット）を購入されたかたは少なからずこう思ってる人がいると思います。

私もそうでした。

audio-diy.hatenablog.com

その後、少しずつ慣れてきましたので遊ぶ中で多用してきたサイト一覧をまとめておきたいと思います。

自分も今後使ううえで探し直したくないですし（←これが最大の理由）。

チュートリアル系

初めてのFPGAやらマイコンやら購入した人はその殆どが開発環境を触ってみるところから始めると思いますが、KRIAはそのあたりビミョーな印象です。

「Vitisにサンプルプロジェクト入ってるから触ってみてね」でしゅーりょーしてます。w

 

これじゃさすがに不親切ではということで、触ってみて再現性の高い（≒初心者でもわかりやすい、ミスりにくい）と思われるチュートリアルページをまとめてみます。

Knitronics

Whitney Knitter氏がまとめているホビーエレクトロニクスブログです。

www.knitronics.com

 

といっても実態はWhitney氏が執筆したHackstar.io（後述します）の記事へのリンクまとめなんですが、このWebサイトから辿ったほうが順序立てて学習できます。

 

ちなみにKR260は下記リンクにありますし、その他AMD FPGAボードを使った様々なプロジェクトがまとめられています。
下記リンク先の内容を一番下から順にしていくとおおよその開発の流れが理解できるかと思います。

www.knitronics.com

 

Hackstar.io

AVNETが運営するハードウェアエンジニア向けコミュニティサイトです。

www.hackster.io

先のWhitney Knitter氏のみならず、FPGA界隈では有名なAdam Taylor氏も当サイトに記事をまとめており、初心者から上級者まで幅広く情報収集できます。

 

リリースされて間もないVitis 2024.2を使って早速KR260を使った記事も出ています。

www.hackster.io

 

渕上 竜司氏のZenn記事

なんとLチカからまとめてくれています。

zenn.dev

zenn.dev

 

その他にもSoC FPGA（CPUとFPGAが統合された夢の(?)デバイス）についていろいろまとめた記事が多く、こちらについても初心者から上級者まで読んで飽きない内容だと思います。

zenn.dev

Linuxイメージ系

KR260（というよりZynqMP系全般？）ですが、その特性故BSP（Board Support Package）やLinuxを都度Buildしているものが多いです。
ただ、このフローが多分「最難関」と言って良いくらいには難しいと思います。

techfactory.itmedia.co.jp

AUDIYも何をミスってるのかわかりませんが、一からBuildしたPetaLinuxで、自身の作成したアプリケーションを動かした瞬間にフリーズしたりとかします。

 

また、AUDIYの経験上、「起動時点から自身の構成したハードウェアを動かしておきたい」といったことがなければ、このあたりはスキップできると思います。

ということで「いちいちPetaLinuxをBuildしたくない！」という人のために評価用イメージのリンク先を共有しておきます（PetaLinuxを一からBuildするとストレージ容量を食いますしね）。

ZynqMP・KRIA用Ubuntuイメージ

KRIAを触ったことのある方はまず最初にUbuntuを動かしていると思いますが、最新のUbuntu SDカードイメージは以下リンク先よりダウンロードできます。

ubuntu.com

2024年12月25日現在ではUbuntu Server 24.04が（Beta版ですが）リリースされていますね。

PetaLinuxイメージ

実はPetaLinuxについても評価用という目的で各種ボード向けにSDカードイメージがAMDから配布されています。

xilinx-wiki.atlassian.net

各種バージョンのReleaseから「SD Image .zip file」よりビルド済Petalinuxイメージを入手できます（入手にはAMDのアカウントが必要です）。

また、この一覧からbspファイル（Petalinuxのビルドに必要）やPrebuilt Firmwareもダウンロードできます。

なお、上記リンク先には2024.1までのリリースしか表記されていませんが、ダウンロードリンクのバージョンを2024.2にすれば最新のPetalinuxイメージもダウンロードできます。
例えば、最新の2024.2のPetaLinuxは以下リンクになります。

https://www.xilinx.com/member/forms/download/xef.html?filename=xilinx-v2024.2_kr260_sdimage.zip

ブートファームウェア

使用するLinuxバージョンによってはブートファームウェアを更新する必要がありますが、KRIAのブートファームウェアについては以下リンク先にまとめてあります。

xilinx-wiki.atlassian.net

ここでの最新版を使えば基本的には良いはずです。

テンプレート系

PetaLinuxを自前の環境でビルドする人や、プロジェクトを立ち上げるたびに必要になるファイルが一部あります。

ここではそこへのリンク先をまとめたいと思います。

soc-prebuilt-firmware

いちからブートファームウェアを作る際に必要なファームウェア一式が保管されています。

各バージョンごとにGitのブランチが切ってあるので、必要なものをダウンロードしてmakeすれば作れます。

github.com

BSPファイル

Petalinuxをビルドする際にBSPファイルを使用する場合のBSPファイルは以下リンク先からダウンロードできます（AMDアカウント必要）。

xilinx-wiki.atlassian.net

XDCファイル

KRIAボードのI/O設定に必要なXDCファイルはXTP685です。
ここから使用しないI/Oをコメントアウトしていくのが良いと思います。

https://www.xilinx.com/member/forms/download/design-license.html?cid=29e0261a-9532-4a47-bb06-38c83bbbb8c0&filename=xtp685-kria-k26-som-xdc.zip

 

RPi HeaderとPmodに絞って動かすのであれば以下リンク先もオススメです。

www.hackster.io

回路図

Starter Kitについては製品ページごとにリンクがあります。

下記はKR260の例です。

www.amd.com

他に疑問が出てきたら

ここから辿ってみると良いと思います。

xilinx-wiki.atlassian.net

ということで、（個人的に）重宝するKRIA関係サイトまとめでした。

 

皆さんも一緒にKRIAしましょ！

Questa - Intel FPGA Starter Editionでのシミュレーションバッチ実行

日記 FPGA Qiita HDL Advent Calender 2024

どうもです。
毎年恒例のこの時期がやってきました

qiita.com

意外と情報が出てこないな・・・・ということで少し書いてみることにしました。

ModelSim/QuestaのGUI実行って面倒くさい

さて、皆様がFPGAのRTLシミュレーションをするときに何を使用されているでしょうか？

などいろいろありますが、これらの大変なところは「VerilogとVHDLを組み合わせたシミュレーションができない」点です（そもそも需要あるのか？という話はさておき・・・）。

混合シミュレーションを実行可能で、無料で入手可能なシミュレータは以下3つになると思います。

  • Questa - Intel FPGA Starter Edition
  • xsim（AMD Vivadoに付属）
  • Aldec Active-HDL Student Edition（学生のみ）

この中でシミュレータを単独起動でき、社会人でも使用可能なものはQuesta - Intel FPGA Starter Editionのみです。

しかし、QuestaやIntelを一からGUIで実行しようとすると

  1. プロジェクトの作成
  2. モジュールとテストベンチのインポート
  3. コンパイル
  4. シミュレーション設定
  5. シミュレーション実行

をマウスを使ってポチポチやる必要があり、結構時間を食います。

www.paltek.co.jp

ということで、効率よくシミュレーションを実行するためにはVerilator等のようにコマンドラインで行うことが欠かせません。

バッチ実行

Questaでシミュレーションを行うにあたりコマンドを一行一行打っても良いのですが、こちらもVerilator等と比較すると手順が多いです。

  1. シミュレーション用ワーキングディレクトリの作成
  2. マッピング
  3. コンパイル
  4. シミュレーション開始
  5. シミュレーション・ログ設定
  6. 実行

ということで、一般的にこれらを一からコマンドで行うことはほとんどなく、バッチファイルを作成して行うことが一般的です。

バッチファイル作成

ということで、ここではざっくりとバッチファイルにまとめるコマンドを紹介します。

詳細な説明は以下リンク先にもありますので、ぜひご参照ください。

www.paltek.co.jp

なお、ここではプロジェクト全体ではなく、比較的小規模なモジュールでのシミュレーションを想定して紹介します。

ディレクトリ作成（vlib）

シミュレーション用のワーキングディレクトリを作成します。
OS標準コマンドでの作成はできませんのでご注意ください。
基本的には「work」という名のディレクトリを作成することが一般的です。

vlib work

マッピング（vmap）

論理ライブラリとワーキングディレクトリをマッピングします。
基本的にライブラリ名とディレクトリ名を合わせておくと混乱は起きないと思います。

vmap work work

コンパイル（vlog/vcom）

ここが少し大変です。

VerilogとVHDLでコンパイルのコマンドが異なったり、言語バージョンによってはコマンドオプションが必要になったりします。

また、複数のディレクトリをvlibおよびvmapで作成している場合は指定して上げる必要があります。

Verilog

オプションを入れない場合、Verolog-2001としてコンパイルされます。

vlog [-vlog95compat|-vlog01compat] hoge.v
SystemVerilog

拡張子svの場合は-svオプションは不要です。

vlog [-sv] fuga.sv
VHDL

オプションを入れない場合はVHDL-2002としてコンパイルされます。

vcom [-87|-97|-2002|-2008] hogefuga.vhd

シミュレーション（vsim）

-cオプションでバッチ実行モードとなります（-cオプションを付けない場合、GUIウィンドウが起動します）。
-tでシミュレーションの単位時間を指定します。
-doの後でシミュレーションの細かい設定を入れておきます。
ここでは"wave.do"というファイルの中身に細かい内容を記載します。

vsim -c -t ns -do "do wave.do; run -all;"

波形確認

vsimを-cオプションと共に実行するとGUIが起動しないため、あとから波形ファイルを開いて確認する場合があります。

その際はvsimコマンドの後に波形ファイル(*.wlf)ファイルを指定すればよいです。基本的には"vsim.wlf"になります。

vsim vsim.wlf

doファイルの中身

doファイルの中身はシミュレーション開始後の設定（波形表示する信号やログを取る信号など）を書いていきます。

add log

観測する信号を指定します。ここに入っていない信号はシミュレーション完了後の波形観測や信号の変化を追跡できません。

add log {/top/module/signal}

-rオプションを付けることで指定した階層以下の全ての信号の観測をすることもできます。大規模なシミュレーションでは実行速度が遅くなりますので注意が必要です。
例えば、以下コマンドでテストベンチ含めた全ての信号を観測できます。

add log -r *

add wave

QuestaをGUI起動する場合はadd waveコマンドで波形表示する信号を指定しておくと良いです。

add wave {/top/module/signal}

実際にやってみる

ここで筆者が普段やってる方法でシミュレーションをやってみます。

簡単なダウンカウンタをテーマにしてみます。
環境はWindowsになります。
Linuxで実行する場合は拡張子".bat"を".sh"にすれば動くと思います。

モジュール本体（CNT_DOWN.sv）

`default_nettype none
module CNT_DOWN #(
    parameter int unsigned BIT_WIDTH = 4
) (
    input  bit CLK_I ,
    input  bit NRST_I,
    output logic signed [BIT_WIDTH - 1:0] CNT
);

    logic signed [BIT_WIDTH - 1:0] CNT_REG = {(BIT_WIDTH){1'b0}};

    always_ff @( posedge CLK_I ) begin: blk_cnt
        if (!NRST_I) begin
            CNT_REG <= {(BIT_WIDTH){1'b0}};
        end else begin
            CNT_REG <= CNT_REG - 1'b1;
        end
    end

    assign CNT = CNT_REG;

endmodule
`default_nettype wire

テストベンチ（CNT_DOWN_tb.sv）

`default_nettype none
`timescale 1ns/1ps
module CNT_DOWN_tb ();

    localparam int unsigned BIT_WIDTH = 4;

    logic CLK_I = 1'b0;
    logic NRST_I = 1'b1;
    logic signed [BIT_WIDTH - 1:0] CNT;

    CNT_DOWN #(
        .BIT_WIDTH(BIT_WIDTH)
    ) u0 (
        .CLK_I(CLK_I),
        .NRST_I(NRST_I),
        .CNT(CNT)
    );

    initial begin
        $dumpfile("CNT_DOWN.vcd");
        $dumpvars(0, CNT_DOWN_tb);

        #23 NRST_I = 1'b0;
        #14 NRST_I = 1'b1;

        #100 $finish();
    end

    always begin: blk_genclk
        #2 CLK_I <= ~CLK_I;
    end

endmodule
`default_nettype wire

バッチファイル（CNT_DOWN.bat）

GUIを出して波形表示までしたいので、vsimに-cオプションは付けていません。
また、最適化オプションやデバッグオプション（-voptargs=+acc、-debugdb=+acc）を付加しています。

vlib work
vmap work work

vlog -sv CNT_DOWN.sv
vlog -sv CNT_DOWN_tb.sv

vsim -t ns -voptargs=+acc -debugdb=+acc work.CNT_DOWN_tb -do "do wave.do; run -all;"

doファイル（wave.do）

add log -r *
 
add wave {/CNT_DOWN_tb/u0/CLK_I}
add wave {/CNT_DOWN_tb/u0/NRST_I}
add wave {/CNT_DOWN_tb/u0/CNT_I}

以上4つのファイルを同一ディレクトリに保存し、バッチファイルを実行してください。

以下のようなメッセージが表示されますが、「いいえ」をクリックしてください。
「はい」を選択するとソフトウェアが終了してしまいます。

すると波形が表示された状態でGUIを操作可能になります。
あとはRadixをいじったり・・・

RTLのブロックを確認したり・・・

自由自在です。個人的にこの「GUIでいろいろ確認できるような状態にするまで」をバッチファイルで自動化すると下準備のほとんどを毎回やる必要がなくなり、非常に便利と思います。

Visual Studio Codeのプロファイル機能を試さないといけない状況に置かれたので試す

電子工作環境 日記 マイコン プログラミング

どうもです。

どうやら半年ぶりの投稿らしいです。

 

ふと気が向いたので、Raspberry Pi Picoを使って、

www.raspberrypi.com

 

CQ出版社のInterface誌で特集されてたビットバンギングを試してみようと思ったのですが、

interface.cqpub.co.jp


Raspberry Pi Pico + C言語で開発しようとするといろいろ面倒くさそうなことがわかってきました。

くわしくはこのあたり（PDF注意）を読んでほしいのですが、なんとCMake必須かつIDEはVScode上に構築する必要があります。

正直この時点で「マイコン初心者はお呼びでない仕様だなぁ」と思ったのですが、PCアプリケーションをC言語で書くことがあるAUDIYからしたら「同じエディタ上で異なるC言語環境が同居する」というのも「できれば避けたい」ことでした。

その他にも「Verilog-2001とVerilog-2005のコーディング環境をスマートに切り替えたい」といったのも常々思っていたところです。

 

なにか良い方法は無いかと探していたら、こんな記事を見つけました。

qiita.com

 

なんと拡張機能や設定を切り替えできる機能があるとのこと。
これは試してみる価値がありそうです。

これまでの拡張機能

ちなみに今までプロファイル機能を知らなかったAUDIYの拡張機能一覧はこちら。

C/C++、Python、Verilog、SystemVerilogなどが混在しています。
何かソースコードを書き始めて保存するまでの間に言語の予測が働くときがあり、少々不便に感じていました。

あとAUDIYは宗教上の理由でVerilog-2001とVerilog-2005を使い分けることがあり、その度にいちいち拡張機能の設定を変更したりとまぁめんどうくさいです。

空のプロファイルを作ってみる

ということで、まずはテスト的に作ったプロファイルに拡張機能が一切ないことを確認します。

「設定」→「プロファイル」を選択して、

 

名前を「Test」とし、「コピー元」を「なし」にして「作成」をクリックします。

 

改めて設定から「プロファイル」→「Test」とすると・・・

 

拡張機能が日本語対応パック以外はまっさら（＝Testプロファイルには拡張機能がインストールされていない）なことがわかります。

いろいろプロファイルを作る

先のTestプロファイルで、デフォルトとは別に拡張機能が（ほぼ）全くインストールされていない環境を新規に作ることが可能ということがわかりました。

 

ということで、C/C++やVerilogなど、開発する環境に合わせてプロファイルをわけていきたいと思います。
ここからはスクリーンショット左側の拡張機能一覧に注目です。

 

C/C++

 

Raspberry Pi Pico

 

Python

 

Verilog-2001

 

Verilog-2005

（Linterの設定を変えているだけなので拡張機能はVerilog-2001と変わりません。）

 

SystemVerilog

 

ちゃんとプロファイルごとに別々の拡張機能を導入できることも確認しました。

実際にソースコードを表示してみる

プロファイルを切り替えて手持ちのソースコードを見てみました。

C言語

 

Python

 

Verilog

 

C/C++やPythonはそんなことはなかったのですが、Verilogだとsvlsとそれ以外のVerilog拡張機能が衝突してカオスな事になっていたので、この機能は非常にありがたいです。

 

さてさてこれから拡張機能ごとに設定詰めていかねば・・・

ところでRaspberry Pi Picoは・・・・

フォロワー氏に譲りました。

正直なところAUDIYにとっては「これならArduinoとかSTM32を選ぶかな」という感想で終わってしまいました。

 

PT8211S DAC基板ができました

自作DAC 自作R-2R DAC 自作USB-DAC 自作オーディオ

ご無沙汰してます。

やっと全部品が実装できました。

PT8211S自体は2022年に秋月電子通商で購入済でしたが、安定化電源が足りなかったり基板設計に時間がかかったり興味が薄れたりでなかなか進んでいませんでした。

audio-diy.hatenablog.com

テスト期間に部屋の掃除がしたくなるように（？）、GWに電子工作したくなったのでさっさと作ってしまいました。

本DACボードの構成

特段変わったことはしていません。DAC出力後のフィルタ回路もPT8211データシート記載の定数で作っています。

データシートを見て疑問に思ったんですが、ポストフィルタ回路がサレン・キー型なのは何か理由があるんですかね・・・？

PT8211ポストフィルタの推奨定数

オペアンプは出力オフセット調整ができるということでSA5534A（5532の1回路・高精度・外部位相補償版です）を使用しました。

www.ti.com

PT8211のデータシートでは、PT8211の電源にRCローパスフィルタを使用していますが「電源ラインに抵抗」というのが個人的には気持ち悪さを感じるのでLT1761を直近で使用する構成にしました。

www.analog.com

ポストフィルタ回路のコンデンサは全てフィルムコンデンサを使用しましたが、データシート上の33pFはDigikeyだと取り扱いが少なく、WIMA一択になります。

www.mouser.jp

音質とか追求するようなICでもないと思うのでC0G特性のMLCCを使用したほうが無難でしょう。

測定環境構築

技術者の端くれたるもの、DAC（というか回路）を作ったからには測定したくなるものです。

実は2年近く前に強力なオーディオ測定機器を購入していました。

このCosmos ADCですが、

innocent-key.com

数万円で手に入る非常に高性能なADCとなっています。また測定に使用するソフトウェアですが、

www.roomeqwizard.com

フリーソフトで測定可能とのことで、ここまで来てしまうとオーディオメーカーは迂闊なものを作れないですね・・・

測定環境構築にはblue-7 (  )氏の以下の記事を参考に構築しました。

qiita.com

いざ、測定！

ということで測定しようと思ったのですが、なんかやたらとTHD+Nが悪い（0.7%ほど）です。

色々見ていくと・・・

状況をまとめると、

  1. 測定用PCと再生用PCは同じものを使用
  2. 電源（PCまたはモバイルバッテリー）にかかわらず、FPGA基板に給電した途端にノイズが現れる
  3. モバイルバッテリーは安定化電源を通じ必ずPT8211S用のレギュレータに対し給電している
  4. PCからFPGAに給電している場合、FPGA基板とDAC基板間のGNDワイヤーを抜くとノイズが消える
  5. モバイルバッテリーからFPGAに給電している場合、FPGA基板とDAC基板間のGNDワイヤーの有無に関わらずノイズが発生する。

これらからFPGA基板上のスイッチングレギュレータのスイッチングノイズがGNDループにより測定機器側に流れ込んでいると予想しました。

ノイズが出ているときのFFT波形は以下のような感じです。

環境を見直して・・・

とりあえずはFPGAへの給電をPCから行い、FPGAとDAC間のGND接続をなくせばループは絶たれるのでその方法で計測しました。

THD+Nが0.062%と、PT8211Sのデータシートと比較して良すぎる値が出ています。

384kHz fsで1kHz正弦波再生時の波形

PT8211SのTHD+N公称値

まぁデータシート上にどんな回路で測定されたか記載もありませんので、データシートの値がかなりマージンを持たせてあるか、AUDIYの測定ミスのどちらかだと思います。

ところで

その他、現状わかっていることとしては相互変調歪（？）がしっかり出ています。

以下、48kHz fsで1kHz正弦波を再生したときのFFTと

48kHz fsで1kHz正弦波再生時のFFT

44.1kHz fsで1kHz正弦波を再生したときでスペクトルに大きな違いが見られます。

44.1kHz fsで1kHz正弦波を再生したときのFFT

同じ1kHz正弦波だと、44.1kHz系統（44.1/88.2/176.4/352.8kHz）と48kHz（48/96/192/384kHz）の間に同様の傾向が見られました。

ひょっとしてと思い、44.1kHz fsで918.75Hz（1000[Hz] * (44.1/48) = 918.75）正弦波を再生したところ、

44.1kHz fsで918.75Hz正弦波を再生したときのFFT

ビンゴです。

352.8kHz fsでも同様の結果が得られたので、再生する音源に含まれる周波数と送信するデータの周波数の差分が悪さしているのは間違いなさそうです。

ということで、出来上がったPT8211S 自作USB-DACのFFT波形を取ってみました。

AUDIY自身まだまだこの測定環境の使い方がわかっていない点も多い（0dBFSの合わせ方とか）ので、理解しながら他の特性（S/N日など）も見ていきたいと思います。

最近ずっとFPGAでしたがやっと電子工作っぽいことができるようになってきました（なおインフレで部品代がツラいです・・・）。

Â