ZYBO 11 ( I2S コントローラの作成 2 ）

DMA部のコーディングも終了した。 転送するのはオーディオデータであり、転送レートは低いので転送長は１（シングルアクセス）とした。

再生側 DMA

録音側 DMA

外部仕様（レジスタ仕様）は幾つか間違いがあったので修正&変更し、サンプリングレートも変えられるようにした。

コーデイングが終わったのでテストベンチを作成してシミュレーションを開始した。

このI2S IPのデータパスはDMACを使うパスと、ソフトウェアでレジスタアクセスによるパスがある。

以下は、AXI-SLAVEのパスによるDAC出力を見ている。サンプリングレートは48Kにし、データとして133.3Hz相当の正弦波を書いている。最下部のdac_l, dac_rはI2Sのシリアルデータをシリパラ変換したデータをアナログ表示している。 

このシミュレーションのテストベクタは以下のように書いている。

write_to_register()とread_from_register()はタスクで、以下のように書いている。

以下は、I2C I/F部を見ている。

ベクタ

こんな感じで録音側やDMAC側も確認するつもりだが、AXI-SLAVE経由でのDAC出力は出来ているので DFT-IP も接続してシミュレーションしてみた。 再生するデータは1.5KHzの正弦波とした。
以下で、xp1, xp2はDFT IPの入力で、moni_l, moni_rと同一信号である。 pwr_dat1, pwr_dat2は、DFT IPの複素出力の実部と虚部の二乗和の平方根である。このDFT IPは2048点のDFT演算を行っている。データの入力点数が増えるにつれて、スペクトルが段々と線スペクトルになっていく様子が判る。

正弦波印加直後






pwr_idxはスペクトルのインデックスを表しており、48KHzを2048点でDFTしているので、23.4375Hz刻みということになる。線スペクトルに対応するpwr_idxの値は65なので、23.4375 x 65 = 1523.4375 Hzと、ほぼ入力信号の周波数と合っている。

ZYBO 10 ( I2S コントローラの作成 1 ）

I2Sコントローラは自作することにした。以下にブロック図を示す。
この内、AXI_Lite SLAVE、I2S_sio、I2C_ctl部のコーディングは終了し、現在はDMA部のコーディングを行っている。

レジスタ仕様は以下のように考えている。 今回の目的からするともっと簡単でも良いのだが、以前作成したAC97用IPの仕様をベースにしたらこうなってしまった。

ZYBO 9 (DFT IPをZynqで動かしてみる）

ようやく、当初予定していたDFT IPをZynqで動かしてみることを開始した。

まずはDFT_IPのコアモジュールの部分をVivadoでIP化することにした。


このIPは2chを同時にDFT演算を行う。入力は16bit整数、出力は32bit浮動小数の複素数である。
フーリエ変換器なので複素数の乗算を行う箇所がある。


以前このIPを作った時はSpartan6用で作成したので、この部分の演算器はXilinxのcoregenでSpartan6用に生成した演算器を使用したが、今回はZynqに実装するのでZynq用に生成し直した。 これらの演算器は自作版も持っていたが、合成後の回路規模がcoregenで生成したものに劣った。 Zynqではどうなるかを見てみた。

coregenで生成した演算器を使った場合の回路規模は以下のような結果になった。

演算器はDSP（ハードマクロの演算器）を使わない設定で生成している。DSPを使う設定で生成すれば回路規模はもっと小さくなると思う。

自作演算器にした場合の結果

こちらもDSPを使用しない条件で合成させた。
やはり、coregenの演算器を使った場合に比べて大きい。

coregenの演算器の方が優っているので、今回も演算器はこれを使うことにしてVivadoでIP化を行った。


この状態で合成できるかやってみた。


合成できた。問題なさそうだ。

今度は、入出力モジュールを作成する必要がある。
以前このIPを作成した時は、AC97コーデックに出力するデータを入力として使用した。
ZyboはAudioコーデックLSIを実装しているがI/FはI2SとI2Cなので、このAC97用IPは使えない。
zybo_base_systemにDigilent製のIPがあるので、これを使うか自分で新しく作るかしなければならない。もしくは、Zynqは12bitのADコンバータ(XADC)も内蔵しているので、それを使うか。。。
まずは、前回と同じことが出来るかを確認したいので前者の方法を検討しようと思う。

ZYBO 8 (dvi_encを動かしてみる）

驚いたことに、もう１１月だ。
この分だとあと２ヶ月足らずで今年も終わりそうだ・・・って当たり前か。

以前、日曜日に３：３０に起床する必要があり土曜の夜に夜更しができなくなったと書いた。  その状況は今も続いていて、というか、今後も数年間は変わらないと思われるが、金曜日の夜は本業の余韻があって思考がFPGAの方に向かないので、やっぱ土曜の夜中にFPGAを弄りたいなぁ−−、どうしたもんか・・・と思案していたのだが、そうだ！ 寝なきゃいいじゃん！  かぁー、その手があったかー、 ということに気づいた。 用事というのはボランティアみたいなもので、遅くても５：００には終わる。 なので、４週間前から土曜の夜は徹夜して用事が終わってから仮眠するようにしている。   ただ、歳のせいか2〜３日後に疲労が来る。　ところが、先週は何故か翌日から体調が不調で眠くはないのだがずっと水中にいるような感じだった。 早くこのリズムに順応したいものだ。

さて、ZYBOだが、思いつきでzybo_base_systemのHDMI Transmiter部を自作のdvi_encに置き換えてみた。
dvi_encではピクセルクロック部とSerdes用クロック部間のデータのクロック載せ替えを下図のようにpvld_x信号で行っていた。

この信号はdvi_encの外部（普通はクロック生成モジュール）で生成していたのだが、今回はdvi_encに一つラッパーモジュールを被せてそのモジュール内で生成するようにした。

これをVivadoでIP化して、DigilentのHDMI Transmiterと入替えた。


合成してみたところ、Serdes用クロックが配線出来ないというエラーが出た。
HDMI TransmiterのRTLを見たら、hdmi_txのSerdesはハードマクロのOSERDESE2が使用されていた。
クロックは別モジュールのAXI Display Controller (axi_dispctrl)で生成されており、クロックバッファはBUFIOが使われていた。 dvi_encはSerdesの部分もユーザロジックとしてHDLで書いており、I/Oバンク専用のクロックバッファであるBUFIOからのクロックは使えない。 そこで、BUFIOではなくBUFRに変更してみた。

これで合成したところ、合成は出来たが若干のタイミングエラーが出た。

クロックのパルス幅が足りないようだ。
試しに、bitデータを作成して実機動作させてみたが動作しなかった。 zybo_base_systemに付属しているデモソフト (base_demo)では、画面の解像度を幾つか指定できる。

この中の最低解像度を選択した場合は以下のような画像が表示された。

その上の解像度では何も表示されず、LCDディスプレイは信号を受信できていないことを示すランプ点滅状態になってしまった。 クロックバッファをBUFGにしてみても同様だった。 ZynqではSerdesの部分をHDLで作成するのは無理そうである。  そこで、Sedes部をOSERDESE2を使うようにRTLを書き換えてみた。

クロックバッファもBUFIOに戻して、合成したところ成功しタイミングもMetした。

動作も最大解像度の1920x1080@60Hzまで問題なく動作した。

HDLで書いたSerdesとこれの合成結果は以下のようだった。


これに対してOSERDESE2使用版の回路は以下のようになった。



ところで、図の左側にあるdvi_encoderはデータをDVIの規格にしたがってエンコードするモジュールである。規格にしたがってエンコードするので、回路はDigilent版も私のもの似通ったものになるような気がする。そこで、両者のこの部分を回路図表示して見てみた。

DigilentのTMDSEncoder

自作のdvi_encoder

両者を見比べると、似通っている気もするのだが回路規模は若干私のほうが小さいようだ。
この図の肌色の箱はフリップフロップやLUT等のプリミティブセルを表しているのだが、数を数えると私の方が少なかった。 Digilent版はVHDLで記述してあり、私のはVerilogで記述している。その差なのか、あるいは、パイプラインの段数に差があるのかも知れない。