Lattice/XO2へのデータ焼きこみ

5Vの電源を準備して、FPGAの焼きこみを完了した。



正常な接続が確認されると、ispDOWNLOAD CableのSTATUSが赤になる。　旧型の中華製コピーモデルだが、動作に問題はなかった。。



ブレッドボードを中継点として電源を供給している。　基板側の接続方法の選択を悩んだが、丸ピン型のICソケットを流用している。　接続ケーブルをブレッドボード準拠にすると、いろいろと作業がやり易い。　





専用のIDEソフトを立ち上げて書き込みを行う過程で、初回は電源の接続を間違えてエラーが出た。　



凡ミスをリカヴァーした後にSTATUSが赤く変化したことを確認して、再度書き込みを行うと一連の作業は瞬時に完了した。



書き込み完了時のIDE。　失敗すると緑の部分が赤くなりFAILの文字が表示される。

FPGAの動作確認は明日以降に行う予定だが、まずはクロックの分周をチェックすることから始めよう。

FPGA試作基板の製作

FPGA試作基板に部品を実装し、ひとまずJTAGからデータを書き込める形になった。

open.theremin＠dacHandlerの設計にミスを発見する

あろうことか、dacHandlerのリセット端子の設定に間違いを発見。　分周カウンタとSIPOフリップフロップのリセット端子の動作論理が逆になっていた。　つまり、端子の状態がどうであろうが、どちらか片方の回路が常にクリアされているという恐ろしい状況に陥る。

これは、SIPOに分周カウンタを付け足す時に両方のリセット回路の動作極性を考慮しなかった単純ミスだが、シミュレーターでは発覚しないタイプの失敗だった。



リカバー不能なバグ以前の問題なので、ADATと同じレベルLOでリセットが行われるように直ちに回路を修正した。画像は、SIPOのリセット端子を修正した後のVHDL。

危惧した通り、インプリメンテーションの結果、端子が大幅に変更されて、半日掛かりの作業は水泡に帰した。　



先ほど再配線を完了したが、





これ以上この手の失敗が発覚しないことを祈るばかり。


続きを読む

open.theremin＠dacHandlerを７chに統一する

ADATエンコーダーに複数のシリ→パラ変換レジスタを接続して使うことには無理がありそうなので、実装するチップの数を減らすことも考慮し、FPGA１チップに回路を詰め込めるだけ詰め込んだ。　流石に８回路を一気に仕込むにはレジスタの数が足りずにアウト、実装限界は7回路だった。



汎用DACへの対応を考えて、ついでにデータ送り信号のSCKを端子に取り出しておいた。



データ入力は、データ、シリアルクロック、共に一本化した。　データを選別するLatchは７回路分を配置している。　そして、ピン配置が劇的に変わった。



結局のところ最終仕様は、オシレーターを個別に6chアウト＋トータルミックスが１ch（同じ音声を２ch並列）となりそうだが、本体の16bitDACとの連携を考えた場合、使い勝手はこちらの方が良いかもしれない。

追記：

FPGAが絡むラインのレベル管理の問題は解決できず、ついにレベル・シフターを追加することになった。　設定の改変を行うと色々とややこしくなるので、出力のオープンドレイン仕様はそのまんま。　

データラインのうち、マイコン端子が絡むWCKのライン1本は5Vのロジック系を混在できないので、こちらは3.3V系で接続して、ADATエンコーダに向かうラインでレベルシフトを行っている。　レベルシフターは4回路あるので、残りはデータライン2本とSCKのラインを充てた。　残りの直結する2本はプルアップで対処している。　
SCKは汎用オーディオDACを接続する際に使用する予定だが、あくまでリザーブ端子扱い。

パワーオンリセットで、カウンタ周りは全てクリアされる。　信号はマイコンから送られる。　ADATの方は独自にスタートアップ回路を充てているが、こちらも一括してマイコン管理にするのもアリ。

dacHandlerのピン配置を修正する

書き込み前にVHDLの回路合成の詳細を確認したところ、やはり無理なピン配置を行っていたようで、信号の精度が保証されていないことが判明した。

このピン配列は、プリント基板上の取り回しを優先したものだったが、Teensy側でCH毎に独立させていたデジタルオーディオ信号の扱いを、データライン共通でラッチクロックのみを独立させる仕様に変更した結果、再度基盤上の配線パターンを合理化する必要が生じている。

この時点で、独自のピン配置に拘る必然は無くなったので、今一度論理合成をやり直すことにした。その結果はこうなって、、、

PAD Specification File
***************************

PART TYPE: LCMXO2-256HC
Performance Grade: 4
PACKAGE: QFN32
Package Status: Advanced Version 1.38

Pinout by Pin Number:
+----------+-----------------------+------------+--------------+------+---------------+-----------+-----------+
| Pin/Bank | Pin Info | Preference | Buffer Type | Site | Dual Function | PG Enable | BC Enable |
+----------+-----------------------+------------+--------------+------+---------------+-----------+-----------+
| 1/0 | Reserved: sysCONFIG | | | PT6C | TDO | | |
| 4/3 | MCK | | LVCMOS25_IN | PL5C | PCLKT3_0 | | |
| 5/3 | rst | | LVCMOS25_IN | PL5D | PCLKC3_0 | | |
| 8/2 | dataOut1 | | LVCMOS25_OUT | PB2A | CSSPIN | | |
| 9/2 | dataIn4 | | LVCMOS25_IN | PB2C | MCLK/CCLK | | |
| 10/2 | ckW3 | | LVCMOS25_IN | PB2D | SO/SPISO | | |
| 11/2 | LATCH3 | | LVCMOS25_IN | PB4A | PCLKT2_0 | | |
| 12/2 | ckW4 | | LVCMOS25_IN | PB4B | PCLKC2_0 | | |
| 13/2 | WCK | | LVCMOS25_OUT | PB4C | PCLKT2_1 | | |
| 14/2 | LATCH1 | | LVCMOS25_IN | PB4D | PCLKC2_1 | | |
| 16/2 | dataIn2 | | LVCMOS25_IN | PB9A | SN | | |
| 17/2 | dataIn1 | | LVCMOS25_IN | PB9B | SI/SISPI | | |
| 20/1 | unused, PULL:DOWN | | | PR5B | PCLKC1_0 | | |
| 21/1 | dataOut2 | | LVCMOS25_OUT | PR5A | PCLKT1_0 | | |
| 23/0 | LATCH2 | | LVCMOS25_IN | PT9D | DONE | | |
| 25/0 | ckW1 | | LVCMOS25_IN | PT9B | PROGRAMN | | |
| 26/0 | dataIn3 | | LVCMOS25_IN | PT9A | JTAGENB | | |
| 27/0 | ckW2 | | LVCMOS25_IN | PT8D | SDA/PCLKC0_0 | | |
| 28/0 | LATCH4 | | LVCMOS25_IN | PT8C | SCL/PCLKT0_0 | | |
| 29/0 | Reserved: sysCONFIG | | | PT7B | TMS | | |
| 30/0 | Reserved: sysCONFIG | | | PT7A | TCK | | |
| 32/0 | Reserved: sysCONFIG | | | PT6D | TDI | | |
+----------+-----------------------+------------+--------------+------+---------------+-----------+-----------+

sysCONFIG Pins:
+----------+--------------------+--------------------+----------+-------------+-------------------+
| Pad Name | sysCONFIG Pin Name | sysCONFIG Settings | Pin/Bank | Buffer Type | Config Pull Mode |
+----------+--------------------+--------------------+----------+-------------+-------------------+
| PT7B | TMS | JTAG_PORT=ENABLE | 29/0 | | PULLUP |
| PT7A | TCK/TEST_CLK | JTAG_PORT=ENABLE | 30/0 | | NO pull up/down |
| PT6D | TDI/MD7 | JTAG_PORT=ENABLE | 32/0 | | PULLUP |
| PT6C | TDO | JTAG_PORT=ENABLE | 1/0 | | PULLUP |
+----------+--------------------+--------------------+----------+-------------+-------------------+


IDEが自動的に配置したピン配列はデータを扱う上で合理的なものだったので、プリント配線の方を新しい仕様に沿う形で基盤を再設計することになる。



論理合成の結果、納得のいく合理的なものが出力されてきたので、下手にこれをいじらずに基盤の設計をピン配置に合わせることにした。 チップ側のキャパシティーは4chまで扱えるので、光出力を視野に入れた構成を考えることにするが、基本構成を2chとして本体側はアナログ2chの出力を固持し、残りの信号処理は欲張らずにピギーバックタイプの拡張方法を考えた方が良いだろう。

dacHandler@MCKとSCK

ADATのAD基板に分周カウンタの導入を失念していた件の影響で、FPGAに組む予定のdacHandlerに内装するSCK信号ラインの仕様が変更になった。

具体的には、64Fsの入力を想定していたSCK入力端子を廃止し、これを256Fs対応のMCK入力とする。　仕様の変更に伴い、FPGA内部で64分周を行っていた6bitカウンタを8bitに拡張し、マスタークロックを256分周したWCKを出力する仕様とした。カウンタは同時に64Fsのクロックを内部出力して、データ読み出し用のSCKを供給する。



コンパイルはすんなり通った。　リソースの消費にはまだ余裕があり、多少の機能変更があってもなんとか対応できそうだ。



pin配置は以下のように変更された。

Lattice系FPGAへの乗り換え

Xlinx系でipfファイルが生成出来ない問題が解決不能な雰囲気になってきたので、ここは潔くプラットフォームの乗り換えを検討することにした。

回路構成がもはやCPLDの規模から外れつつある状況から、より許容量の大きなFPGA系のチップを探していたところ、XO2というのを発見した。　

ターゲットとなるデバイスはパッケージがSMT32と極小で、端子数もよい感じにまとまっている。

FPGAチップ一個で、4ch/DAC2個分のハンドリングが可能。　チップ2個で、ADATにフル対応できる。（という想定）　サイズが倍にはなるが、処理能力が高い上位機種ではチップ１個で8chを捌ける可能性がある。

QFN32と、チップサイズが極小になったのはOpenTheremin的視点から嬉しい。」

で、Latticeのツールに乗り換えた途端に丸一日悩んでいたことがウソのように解決した。　



FPGA側に64分周回路を仕込むと、クロックラインがシンプルになる。要はWCKとSCKを一系統のラインに纏めるのだが、リソースの消費が分周回路分増える一方で、ReadClockが1端子減って、物理的に余裕が出来ることになる。



ちなみに、ADAT系のチップはWCKからビットクロックを内部生成できるので、出力信号のラインはWCKとデータライン4本だけで成立する。ADAT以外のデバイスを使用する場合の汎用性を確保するためにSCKは外部入力とし、それを分周したWCKを出力する。 データ送出タイミングの精度さえ確立していればよいので、やはりFPGA内部で分周を行うのが正解と思われるが、厳密にはこの部分で「完全同期」を行う必要があるかもしれない



SCKはFPGAの送出系のマスタークロックとして扱われる。WCKは出力端子に変更する。

dacHandler(仮)のシミュレーションを行う段階で、ハンドリングするデータの規格を統一する必要があるのだが、設計自由度の高い3線方式を採用するのが現実的だ。

これには、動作が確認されているAD420用の仕組みを採用するとして、データの扱いはDAC1単位を4ch分=12pinの信号を捌かなければならない。

ADATへの送信フォーマット準拠でデータを出力する場合は、WCKは1chで良いので、送り側はADATへのデータの読み出しに合わせて、2chペアで信号を送出することになる。

送出側の送信タイミングを外部から入力されるWCK準拠とした場合、現在は受け側でクロック数をカウントして発生させているいるラッチ信号を、送出側から供給した方がデータの取りこぼしが発生し難い。

安全策として、新たに受け側のシステム内部にD-FFによるデータ固定機構を構築するのが理想的だが、リソースに余裕がない場合は、現在の回路でW/Rのタイミングを詰めることになる。とはいえ、AD420用に書かれたスケッチでは、32クロックを生成後に送信側のタイミングでLatch信号を出力しているので、原理的に間違いは発生しないだろう。

Latticeにチップを乗り換えた結果、実装可能な回路規模が判明したので、これからはより汎用性の高そうな送受信のフォーマットを決定しなければならない。

プログラミングツールを探していて見つけたのがコレで、3kチョイと安かったので迷わず購入。



手持ちのXlinx製を転用するのに掛かりそうな手間を考えると、専用機を揃えるのが正解か。

VHDLコードの方は、SCKを64分周する回路を加えて（内部でクロックを32カウントしていたカウンターを復活させた）WCKを出力に回すように改装したものを論理合成できた。　



動作スピードが落ちることとトレードオフで、ピン配列もそれ風にまとめてある。



信号の極性など、間違えている可能性があるのでシミュレートしたいところではあるが、Webpack ISEから起動していたシミュレーターをスタンドアロンで扱う方法が判らず、起動方法を探しているところ。