HDLソースに制約を埋め込む [IPコア]

QuartusPrimeではソースファイル側にハードウェアやタイミングの制約を埋め込むオプションがある。
一番よく使うのは、クロックドメインをまたぐレジスタのタイミングパスを切る指示。
これは一般的なフローではSDCファイルに記述するが、どのレジスタがタイミングを無視していいかなんてのはソースに一緒に書いた方がわかりやすい。

記述はHDLの中にaltera_attribute属性の文字列を埋め込むことで行う。これはQuartusへ合成指示を渡すオプションで、qsfファイルに記述するテキストと基本的には同一。
‥‥が、Verilogではアトリビュート記述は一行に納めないといけないので、複数行に分割しないとSDCに書き出すよりも遙かに見難いソースが出来上がるので注意が必要。

・Verilog-2001
(* altera_attribute = {"-name SDC_STATEMENT \"set_false_path -from [get_registers *sv_xcvr_pipe_native*] -to [get_registers *altpcie_rs_serdes|*]\"; -name SDC_STATEMENT \"set_false_path -to [get_registers *altpcie_rs_serdes|fifo_err_sync_r\[0\]]\"; -name SDC_STATEMENT \"set_false_path -to [get_registers *altpcie_rs_serdes|busy_altgxb_reconfig*]\""} *)


・VHDL
attribute altera_attribute : string;
attribute altera_attribute of rtl : architecture is (
"-name SDC_STATEMENT ""set_false_path -from [get_registers *sv_xcvr_pipe_native*] -to [get_registers *altpcie_rs_serdes|*]"";" &
"-name SDC_STATEMENT ""set_false_path -to [get_registers *altpcie_rs_serdes|fifo_err_sync_r\[0\]]"";" &
"-name SDC_STATEMENT ""set_false_path -to [get_registers *altpcie_rs_serdes|busy_altgxb_reconfig*]""
);


FM音源のDACインターフェース解析の更新 [IPコア]

以前やったFM音源のDACインターフェース解析(2015-11-06)のつづき。

どうもYMF262の波形がおかしいという話になり、実機を調べてもらったところ、fsが14.318MHz÷256ではなく14.318MHz÷288だった。
YMF262はDACとしてYAC512を接続するのだけども、このビット長が16bit×2なのでそれをデータフィールドと勘違いしてしまったようだ。実際には16bit長のデータの前に2bitのダミーがあり、全体では18bit×2のデータフィールドになっている。
でもデータクロックのデューティ比が25%とかいうのは一緒。あんまりピン遅延とかボード遅延とかシグナルインティグリティとかをとやかく言われなかった時代っぽい感じはする。

あと変態的な信号を発生するとして一部のスジでは名高いYMF297も実機を測定してもらったので、データとして追加した。一緒にYM2203も調べて貰えばよかったか‥‥。

DAC出力フォーマット_20160926.pdf
※9/26追記:YM2151のクロック極性が逆になってたので修正しました

あと、C140の動作クロックとDACクロックがいくつなのかご存じの方いましたら@s_osafuneまでリプお願いします‥‥<(_ _)>

system2.jpg

NiosIIのROM化ではまった備忘録 [IPコア]

いつのバージョンからか詳細には不明だけども、ROM化がうまく動かなくなった。
症状としてはEPCSからの自作ブートコピアからアプリケーションへのブランチがうまくいかないというもの。

NiosII Gen2のあたりからそういう報告があったので、キャッシュか、Gen2になって何かハード的に追加されたのだろうなー、とか考えていたら、原因は全然違うところにあった。

原因は大きく2つ。
(1)BSPを-O3でコンパイルするとrwdataセクションの初期化にmemcpyが使われる。
(2)elfファイルのセクションテーブルのpaddrフィールドが使われるようになっている。

NiosII SBTでBSPを作成すると、main関数が呼ばれるまでにメモリやPOSIXの初期化が行われるが、その中で組み込みC言語では必須になるrwdataセクション(初期値付きデータ領域)の初期化のために、元データからメモリへ値の転送が行われる。
この時点ではC言語が動作する前提がまだ整っていないため、原則としてはアセンブラで行わないといけないのだが、NiosII SBTでは普通のCで書かれているためGCCではメモリ間コピーだと推測して勝手にmemcpyを呼ぶように変更してしまう。
こと組み込み関係では標準関数がどう実装されているかは環境によるため、初期値付きデータ不定の状態で正しく動作するかは保証ができない(どうも今回の場合では期待通りの動きをするようだ)。

二つ目の方は既存のROM化ツールを使っていたので発覚した問題。
どのバージョンから変更になったのかは不明だが、NiosII SBT 16.0のリンカスクリプトではBSPの設定としてtext、rodata、rwdata、bssのセクション名は存在しているものの、elfファイルに結合された時にはbss以外は一つのセクションにまとめてしまう。
このときBSPで初期化ロードのオプションを付けていると、rwdataの初期値データのみをRO属性のセクションとして切り出すが、elfファイルのセクションテーブルのアドレスフィールドの設定がちょっとまずい(というか互換性の問題が出る)値になる。

GCC3まではVADDRフィールドのみが使われ、rwdataの元データとメモリ転送先の2つがそれぞれ別のセクションとしてテーブルに存在していたが、NiosII SBT 16.0ではrwdataの元データのみがセクションになっていて、ソフト実行時に参照するメモリ上のアドレスを示すVADDRフィールドと、ロード時にデータが存在するアドレスを示すPADDRフィールドが使われている。
既存のツールではVADDRフィールドの値でロードアドレスを決定しているため、これをそのまま使うと初期化前にrwdata領域に値を転送し、初期化ルーチンではからっぽの初期値データで上書きしてしまうことになる。


対策としては、アプリケーションロードに関してはrwdataの初期化を初期化ルーチンで行わない(BSPで初期化ロードのオプションを外す)ことで対処する。
こうするとrwdataの初期化は、ロードされたプログラム側ではなくロードするブートコピア側で行われることになるため、(1)(2)の問題は発生しない。

この場合、ロードされたプログラムの再エントリ時に初期値が戻らないというデメリットがあるが、そもそもEPCSからのブートコピアであればリセット後には必ずセクションのロードが行われるので運用上では問題ない。


へたにROM化するよりも、大容量メモリをつけてファイルシステム付きのブートローダーでelfを実行するIPL環境を標準にした方がいろいろ楽になると痛感した一幕でした。睡眠時間と終電をかえせ。

FM音源のDACインターフェース解析 [IPコア]

ちょっと必要になったので、各方面のご協力のもと各種FM音源のDACインターフェースフォーマットを調べた。
音源チップのレジスタや蘊蓄なんかは多数引っかかるのだけど、やっぱりソフトからもボードからも見えない部分の情報はなかなか出てこない。

まとめたのは、YM2151、YM2608、YMF262、YMF288の4つ。YM2203はフォーマットそのものはYM2151と同じなのだけど、モノチャネルなのでクロックが半分になってる可能性があるのだがよく分からなかった。

DAC出力フォーマット_20151106.pdf
FM音源のDACインターフェース解析の更新(2016-09-26)に続く

system2.jpg

Packet to Transactionコアの動作について [IPコア]

QsysにはSPIやJTAGを使ってAvalonMMペリフェラルを操作できるAvalonMMバスブリッジモジュールがある。

SPI Slave/JTAG to Avalon Master Bridge Cores(pdf)
SPI Slave to Avalon Master Bridge Design Example

これを利用すると、NiosIIや自作AvalonMMマスタを使わなくてもQsysの中身を自在に操ることができる。
特にリソースの少ないMAX II/Vにちょっとしたペリフェラルを組み込んで制御するとか、FPGAの中身にテストでレジスタ操作をしたいというときには非常に便利な機能なのだけど、どうにも資料が揃っていない。
なので、ちょっと調べてみた。


・トランザクションの本体

SPI Slave/JTAG to AvalonMM Bridgeは単体のコアではなく、物理層・パケット層・トランザクション層の3つのレイヤからなる。このうちAvalonMMマスタとして振る舞うのはトランザクション層のコア(Packets to Transaction)になる。

このコアが処理できるパケットはコマンドヘッダにより4種類ある。
実際にはリード/ライトの2種類に対してそれぞれシングルとアドレスインクリメントの2つがあるので4種類ということになる。
基本的には

CMD 0x00 SIZE(U) SIZE(D) ADR(UU) ADR(UD) ADR(DU) ADR(DD)

という共通の8バイトのパケットを流す。ライトの場合はこの後に書き込むデータを続ける。
SIZEはデータのサイズを指示する16bit長のデータ、ADRはアドレスを指示する32bit長のデータで、この2つのフィールドだけはネットワークバイトオーダーで指定する。

ただしQuartusII 13.0時点で、SIZEフィールドはリード時しか使われておらず、ライト時は後続のデータをカウントして書き込みサイズを取得するような実装になっている。

(1)シングルライトパケット

0x00 0x00 SIZE(U) SIZE(D) ADR(UU) ADR(UD) ADR(DU) ADR(DD) D0 D1 … Dn

を送る。DATAは4バイト以下でなければならない。バイトアドレスの若い順から並べる(※アドレスフィールドとはバイトオーダーが逆になる)
また、アドレスは書き込むデータ長が32bit境界を跨ぐような指定をしてはならない。
下のような4バイトのライトレスポンスを返す。

0x80 0x00 SIZE(U) SIZE(D)

データは32bit単位で書き込まれるので、デスティネーションにバイトイネーブル機能がない場合、32bitデータ幅が全て書き換えられてしまうことに注意する。

(2)インクリメンタルライトパケット

0x04 0x00 SIZE(U) SIZE(D) ADR(UU) ADR(UD) ADR(DU) ADR(DD) D0 D1 … Dn

を送る。DATAは最長65535バイトまで可能。バイトアドレスの若い順から並べる(※アドレスフィールドとはバイトオーダーが逆になる)
アドレスは開始バイト位置を指定する。
下のような4バイトのライトレスポンスを返す。

0x84 0x00 SIZE(U) SIZE(D)

インクリメンタルライトではデータは自動的に32bitにアラインメントされて書き込みが行われるため、これでレジスタに連続書き込みをする場合は、バイト単位でデータを送っていても32bit単位にまとめられて書き込みが発行されることに注意しなければならない。
特に非アライメントの転送をする場合にデスティネーションがバイトイネーブル機能を持っていないと、余計な部分まで書き込みがされる。

(3)シングルリードパケット

0x10 0x00 SIZE(U) SIZE(D) ADR(UU) ADR(UD) ADR(DU) ADR(DD)

を送る。SIZEは読み込みバイト数で1,2,4のどれかを指示する。アドレスは読み込みバイト数が32bitアライメントを跨がないようにする。
下のようなリードレスポンスを返す。

SIZE = 0x0001の場合 : D0
SIZE = 0x0002の場合 : D0 D1
SIZE = 0x0004の場合 : D0 D1 D2 D3

AvalonMMの仕様として、リードは必ずデータビット幅(32bit幅)単位で行われるため、リードで状態が変わるソースに対してバイト/ハーフワードのリードをした場合、読んでいない部分のレジスタもリード扱いになるので注意すること。

(4)インクリメンタルリードパケット

0x14 0x00 SIZE(U) SIZE(D) ADR(UU) ADR(UD) ADR(DU) ADR(DD)

を送る。SIZEは読み込みバイト数で65535バイトまで指定。アドレスは開始バイト位置を指定する。
下のようなリードレスポンスを返す。

D0 D1…Dn

開始アドレスからのバイトを返す。ただしシングルリード同様に、内部では32bit単位のリードを行っているため、アライメントに合わないアドレスあるいはデータ数を指示した場合、指定されていないアドレスのデータバイトをリードする。
リードによって状態が変わるソースにアクセスする場合には注意が必要。



パケット層と物理層のバイトエンコードはデータシート見れば分かるので省略。

Packet to Transactionの動作はなかなかよく出来ているので、結構トリッキーな使い方もできそう。
実はインクリメンタルとシングルの差はアドレスのカウントアップをするかしないかだけで、ステートマシンは同じなので、シングルライト/リードのパケットに32bit以上のデータを付けても動作するし、32bit非アラインメントから32bitデータの読み書きをしても、一応2つのトランザクションに分割してアクセスする。

ただしアドレスは増えないので非常に怪しいデータが書かれる。ついでに、シングルリードで非アラインで複数リードをすると、2回目以降のバイトイネーブルが正しく動かないようだ。

シングルリード/ライトで連続データを扱うと、うまくすればFIFOなんかの揮発性ペリフェラルから一度にデータを転送できるが、はまるとドツボなので、デバッグの手段がさっと思いつかないレベルの人はやらない方が賢明ではある。