2013年7月28日日曜日

ヘッドフォンアンプ

DDR3 SDRAMCはその後72時間ほど連続動作させてみたのだが問題なく動作した。次は、PCIeからアクセスしたいと考えている。

今日は別の話。

先日解体したジャンクの16ch mixerの基板の中にヘッドフォン用のアンプ基板があった。

このアンプ基板はNECのuPC1238という10Wパワーアンプ用のICを使っていてスピーカーの駆動もできそうだ。  そこで、この基板を使ってアンプを作ってみた。

uPC1238は両電源が必要だが、トランスの手持ちが無かったのでDC/DC電源+レールスプリッタという方式にした。DC/DC電源はJRCのNJM2360ADで作成した。  パネル取り付け型のDCジャックの手持ちが無いため、一時的に基板取り付け用DCジャックを使用している。ヘッドフォンとスピーカーどちらも接続できるようにする予定なのだが、DCジャックを入手したらケースの穴あけ追加工のためにバラす必要があるので、現状はスピーカー用端子への配線はしていない。


DC/DCのスイッチングノイズの音質への影響の不安があったのだが、私の貧弱な聴力では気にならなかった。こんなの初めてっちゅう位にすごく良い音に聞こえる。

こんな風にセッティングした。





2013年7月16日火曜日

LatticeECP3用DDR3 SDRAMCの snapshot

LatticeECP3用DDR3 SDRAMCの snapshot 版をいつもの、

<http://www.hi-ho.ne.jp/bravo-fpga/>

に置いた。

LatticeECP3用DDR3 SDRAMCの作成 12

failの原因は、テストモジュールのバグだった。 orz
アドレスレジスタのビット幅が1bit多かった。そのため、DRAMの領域を2分割してそれぞれのモジュールに分担させているつもりがそうなってなかった。。。 

そこを修正したら正常に動作するようになった。
video

テストモジュール2つ実装してなかったら、最終的には発覚したとは思うが、暫くは気付けずにいたかも知れないので、その意味ではこのテストをやってよかった。
しかし、バカだねぇ~→→俺。 あ゛ーっ、もう。  (>_<)"ゝ

でも、これで次に進める。


2013年7月15日月曜日

LatticeECP3用DDR3 SDRAMCの作成 11

LFSRを使ったR/W テストモジュール 2つによるアクセス試験の場合にfailが発生する問題を調べている。テストモジュールを修正して、1回めのfail発生時のアドレス、レングス、データの初期値、そして何ワードまで受信していたかを示すカウンタ値をレジスタに保持し後からUART経由でリードできるようにした。 PC側のプログラムは以下のようにした。通常は各カウント値をポーリングし表示し続けるが、何れかでfailが検出されたらループを抜け、保持されている値をリードして表示しプログラムを終了する。

これを実行したところ、以下のような結果が得られた。 xx_ADR_BKの上位側8bitはレングス値、下位側24bitはアドレス値、xx_RCNT_BKは何ワードまで受信していたかを示すカウンタの値、xx_ECP_BKはリードデータの期待値、xx_RDT_BKはリードされた値である。

上記はRW1_FAIL_Cが3、RW2_FAIL_Cが0となっており、RW1側でのみfailとなっていることを示している。興味深いことに、FPGAをリセットして再度プログラムを実行しても同じアドレス、同じRCNT値の箇所でfailが発生し、xx_RDT_BKの値も同じであった。

しかし、このデータではリードされたのがどういう素性の値なのか判らないので、乱数の代わりにアドレス値をデータとして書き込むように修正して再度実行してみた。こんどは以下のような結果になった。赤線の箇所の値が異なっている。

 FPGAをリセットして再度実行しても同じ結果になるので規則性があるようにも見える。
値が化けているところを見るとタイミングマージンの問題か?という気もするが、だとして、何回試行しても同じ化け方になるもんだろうか???  チェックモジュール1chだけでの動作を昨晩中走らせてみたが問題なかった。2ch動作させた場合にfailが発生する。シミュレーションで確認したいのだが、passカウントの値が3000のオーダーに達するのにこれまた一晩位を要する。波形ファイルもmodelsimのwlf形式で4GBを越えてしまっていた。したがって、上記結果にあるように80000のオーダーまでシュミレーションして確認するというのは現実的では無い。 XilinxのChipscopeやALTERAのSignalTapのような仕組みがLatticeにもあり、Revealというらしいのだが、果たしてこれを使うべきか。。。  観測したい信号は125MHzまたは250MHzで動作している信号になる。これをサンプリングして見るためにはサンプリングクロックは250MHz以上を使う必要がある。見えるか・・・というか、Revealを入れてタイミングがMetするか???

何とか工夫して解析するしかないか...うーむ。


2013年7月14日日曜日

つまみの洗浄

先日、PA用16ch Mixerのジャンクを分解した。4~5年前にある楽器屋さんの閉店セールでこのジャンク品を見つけて買ったのだが、ずっと仕舞いっぱなしだった。かさばるので思い切って処分することにし分解したのだが、勿体ないので幾つかの部品は採っておくことにした。その時に沢山採れたつまみ類をFPGAのシミュレーションの合間に洗浄してみた。まず、過酸化水素水を含んでいる弱酸性の洗濯用洗剤の溶液に浸して暫く天日干しする。その後、水洗いをしてからティシューで水気を拭き取った。

なかなか綺麗に洗えた。♪


未洗浄品と洗浄済品との比較。橙、黄色それぞれ左が未洗浄、右が洗浄済み


まだ、こんなに残っている。


明日、晴れたら残りも洗浄しようっと。

LatticeECP3用DDR3 SDRAMCの作成 10

デジタルオシロに続いて、もう一つだけ測定器を入手した。プログラマブルDC電源である。アナログ回路の実験等をやる場合に一つ欲しいなぁーと思っていたのだが、今回、デジタルオシロを購入したのとは違う中古測定器販売サイトで格安のものを発見し購入した。購入したのはAgilentのE3631Aという80W 3出力のプログラマブルDC電源だ。この機種は現在も製造・販売されており、新品はRSコンポーネンツ等からも購入可能なようだ。私が購入したのは中古品なので定価の1/5程度の値段だった。1ケ月の保証付きだった。このお店は校正機関への取り次ぎは行っておらず、したければ自分で何とかしてねっというスタイルのお店だった。


さて、DDR3 SDRAMCだが、これまではUSB-UART経由でメモリのリード/ライトチェックだったのでどうしてもアクセス間隔が開いてしまうので、LFSR、所謂M系列乱数発生器を用いたリード/ライトチェックモジュールを作成し、これによるチェックを行おうとしている。 私がLFSRというのを知ったのは、昔々、工学社のI/Oというパソコン系月刊誌(この月刊誌は今も発刊されているようである。)の別冊本でLFSRを使ったM系列乱数発生器の製作記事を読んだ時だ。シフトレジスタの途中の値をExORを介して初段に戻す回路を見て、へぇー、こんなに簡単にできるんだーっと思った。今回のモジュールを作成するにあたり、帰還多項式についてはwikipediaの記事を参考にした。

回路の概略動作は、まず、LFSRでリードライトする領域の開始アドレスと長さを得る。次にその領域に対してLFSRで発生させたパターンをライトし、次に、その領域をリードしてライトしたパターンが正しくリード出来ることをチェックする。データが全て一致したら pass countを+1し、不一致があった場合は fail countを+1する。この処理を繰り返し行う。また、チェックモジュールは2つ実装し、両モジュールによる競合試験もできるようにした。但し、同じ領域へのアクセスの競合を許すと、#1のモジュールがライトした後に#2のモジュールのライトが割り込んで、その領域を別の値で書き換えてしまい、その結果、その後の#1のリードチェックチェックでエラーとなってしまうため、領域は分けるようにしている。具体的には、メモリ領域は2分割しそれぞれを個別に担当させるようにした。

LFSRモジュールは以下のような感じで作成した。これはアドレス用の24bit LFSRである。初期値はパラメータ INIT とし、インスタンス毎に定義できるようにした。また、動的な値のロードもできるようにした。


全体の動作はステートマシンで制御している。

ST_IDLEは初期ステートであり、do_chkが1になると動作を開始する。ST_RANDはST_IDLEまたはST_STALL2からST_RAND遷移のタイミングで生成された乱数をそれぞれのレジスタにラッチさせるためのステートである。ST_WR_REQはDRAMCのMPIFポートに対してライト要求を行うステートでこれが受け入れられると次にST_SND_DATAに遷移し、ライトデータの転送を行う。これが完了するとST_STALL1に遷移し、しばらく待つ。この待ち時間の値もLFSRで生成している。当初は8bitで最大256サイクルまで待つようにしていたが、大きすぎるので8bitの下位4bitのみを使うこととし、最大16サイクルまでとした。ST_STALL1での待ちが完了するとST_RD_REQに遷移しMPIFに対して先ほどライトした領域のリード要求を行う。これが受け入れられると、ST_RCV_DATAに遷移してリードデータを受信する。書き込んだ数分のデータ受信が完了したらST_STALL2に遷移し、ここで再びストールする。この時の待ち時間はST_STALL1の時間と同一とした(特に意味は無い)。 ST_STALL2での待ちが完了すると、再びST_RANDに遷移し処理を繰り返す。

アドレスとデータ数についてはいっぱい-いっぱいのビット幅で生成しているので、アクセス範囲が担当領域を越える事も想定される。そこで、アクセス範囲が領域を越えるか否かをチェックし、越える場合は範囲を修正するという処理を行うようにした。


リードデータの照合は以下のようにしている。

ライトデータの初期値を保持しておき、これを期待値生成ようLFSRに初期値として設定し、リードデータが到着する度にパターンを生成させてこれとリードデータとを比較する。一致しない場合はフラグ f_fail が1になる。このフラグは1になると、そのリードサイクルが完了するまでは1を保持する。リードサイクル完了時に、pass_cntとfail_cntはf_failを参照し、その値に応じて各々を更新する。

以下はシミュレーション波形である。



以下のUART経由のアクセスと比べると、UART経由のアクセス密度が如何に低いかが判る。


次に実機で動作させた。
制御プログラムは以下のようになっており、RWCHK_CTRLに書き込む値によって、1モジュール単独動作または2モジュール同時動作を設定(起動)し、以降はそれぞれのpass count値とfail count値をリードし表示し続ける。


これで2モジュールを同時に動作させた。結果、頻度は低いがfailが発生するようだ。
video

1モジュール単独では1時間以上動作させてもfailは発生しない。

#1のみの場合
video

#2のみの場合
video

現在、DDR3は500MHz (1Gbps)で動作させているが、これを400MHz (800Mbps)に落としても同様であった。もしかすると、DRAMCよりも上位のMPIF周辺に問題があるのかも知れない。。。

うーむ。。。

2013年7月6日土曜日

デジタルオシロ

遂に、デジタルオシロスコープを入手した。
従来所有していたのはストレージ機能の無いアナログオシロスコープで帯域150MHzの機種だが、ストレージ機能が無いと何かと不便で、やっぱし、デジタルオシロスコープが欲しいなぁー、しかも広帯域の。って思っていたのだが、今回、漸く自分でもなんとか購入できる価格の機種を中古測定器販売サイトのページで発見し、無事購入できた。。。というか長年の願望だったので殆ど衝動買いである。価格はZynqボード2枚分+消費税な値段だった。



購入できたのはHP (現 Agilent)の54616C というもので、2Gサンプルで帯域500MHzの2CHデジタルオシロスコープだ。本体の他に帯域500MHzの新品のパッシブプローブ2本が付属していた。購入後6ケ月の無償修理保証もあり、その保証書も付属していた。初めて利用した業者だったが、対応もしっかりしていて良かった。校生機関への取り次ぎサービスも行っているらしい。取説は付属していなかったが、メーカーのサイトから入手できた。

ホント、長年欲しかったデジタルオシロスコープなので入手できてうれしい。
梱包箱を開梱するときも自然と笑みが溢れてしまった。。。ムフッ

次は、なんとか卓上旋盤を…


GTX1050Ti と Tesla m2050 No.2 (BNN-PYNQのtrainingをやってみた)

BNN-PYNQのtraining(学習)をやってみた。  手順は https://github.com/Xilinx/BNN-PYNQ/tree/master/bnn/src/training に記載されており、特に判りづらい点はなかった。 ・ mnist.py 実行...