VHDLいろいろ [FPGA]

今更感あるけども、VHDLで特定用途で便利な記述ネタを。

●コンポーネント宣言を省略する

use work.all;

を追加すると読み込んだエンティティのコンポーネント宣言を省略できる。VHDLの悪名の半分はこれで解消。
注意点はModelSimではコンパイル順で認識するので、ソースファイルの順番に依存してしまう。Quartusでは全てのファイルを読み込んでから評価するみたいなので同じプロジェクト内のソースであればどこでも参照できる。

●LPMやMegafunctionを直接インスタンスする

library altera_mf;
use altera_mf.altera_mf_components.all;
library lpm;
use lpm.lpm_components.all;

を追加しておくと、コンポーネント宣言を省略してLPMやMegafunctionのマクロをインスタンスできる。
乗算やFIFO、DDRIOなどハードマクロにインスタンスしたい場合に便利。
パラメータのマニュアルはIP Catalogで表示されるコンポーネント名でぐぐれはIntelのpdfがでてくるけど、そのままIP Catalogでソースを出力して該当部分をコピペした方が早い。

そんなわけで、ソース公開するときにライセンス云々でやかましい類の人間に噛みつかれたくないときに重宝。別にQuartusPrimeのツール生成ソースでライセンス上も何の問題も無いのだけれど。

●リダクション演算を使う

use ieee.std_logic_misc.all;

を追加すると以下のリダクション演算ファンクションが使えるようになる。

and_reduce(std_logic_vector)
or_reduce(std_logic_vector)
xor_reduce(std_logic_vector)
nand_reduce(std_logic_vector)
nor_reduce(std_logic_vector)
xnor_reduce(std_logic_vector)

リダクション演算は引数のベクタの全ビットに対して論理演算を行うというもの。例えば and_reduce(data) とやると、dataの全ビットでand演算を行った結果が返される。つまり全ビットが'1'なら'1'が返る。
or_reduce(data)であれば全ビットが'0'の場合に'0'が返る。xor_reduce(data)では'1'のビットが奇数個の時に'1'が返る。
or_reduceは関係演算子でオーバーロードが行われるのでゼロ比較で代用できるけども、and_reduceの機能(任意長のビット幅で全ビットが'1'の判定)は少々面倒なので、パラメタラブルな記述をし始めると出番は多い。


NT京都2017開催! [雑談]

NT京都2017が今年も春のお彼岸中に京都西院春日神社にて開催されます!
NT京都2017_トップ真面目過ぎ_軽量版.jpg

NT京都とは
「おもしろい」と思った物を後先考えずに作ってしまう人達の作品70組超が京都西院に大集合します。毎年「訳わからんけど、おもろいな」と評判のNT京都は今年で8年目。普段はウケを狙って面白作品を開発しインターネットに動画投稿している人達(ニコニコ技術部)の有志が緩い雰囲気で運営しています。

開催日時
3月19日(日) 9:30〜16:30 入場無料

その他、詳しくはニコニコ技術wiki NT京都へ!

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環境を標準にした方がいろいろ楽になると痛感した一幕でした。睡眠時間と終電をかえせ。