SSブログ
前の5件 | -

NiosIIカスタム命令のつくりかた [Platform Desginer]

インテルFPGA Advent Calendar 2020 の23日目担当で、NiosIIのカスタム命令についての記事を書きました。

NiosIIカスタム命令のつくりかた

On-Chip Memoryの初期値ファイル [Platform Desginer]

Platform DesginerのOn-Chip Memoryペリフェラルで初期値ファイル(HEXまたはMIF)を設定する場合、右のファイルボックスから選択すると絶対パスになってしまい再配布がめんどうになる。
そこで初期化ファイルをプロジェクト相対パスで指定する方法を2つ紹介。

1.相対パスを記入
EpoWgJgVgAUuTAb-orig.png

Platform Designerのコンポーネントはプロジェクトルートをカレントとするので、プロジェクトフォルダ以下の相対パスをそのまま指定すればいい。
ただしLinux環境では ./~ で記入しないと認識されないことがある様子。

2.プロジェクトルートに配置
EpoWy0dVgAE5kEF-orig.png

QuartusPrimeの機能として、プロジェクトルートにあるファイルは暗黙的にプロジェクトに追加されたファイルと見なすので、ファイル名のみ記述して本体をプロジェクトルートに置く。
ブートローダーみたいなファイルはこちらの方が運用が楽。


どちらの方法をとる場合でも、初期化ファイルが認識できないとQuartusはCritical Warningを報告する。
EpoYO82VQAA4iIQ-orig.png

ちなみにメモリに対して初期化データの要素が足りない場合も同様にCritital Warningを出す。
ファイルが無い場合はメモリは全て0でフィルされ、足りない場合は未定義部分が0でフィルされる。

Avalon-MMバーストマスタのbyteenable信号 [Platform Desginer]

ずいぶんと偏った項目ではあるけれども、自分自身がちょっと勘違いして覚えていた部分があったので改めてAvalon仕様書 20.1でどうなっているのかを確認してみた。

・Avalonインターフェースとは

改めて説明する必要があるかどうかはさておき、AvalonインターフェースというのはIntel FPGAのIPコアで使われるメモリバスおよびデータストリームの規格です。
これはQuartusPrimeのツール群であるPlatformDesigner(旧Qsys、もっと古くはSoPC Builder)でコンポーネント間の接続インターフェースとして定義され、この規格に則った動作をするHDLに加えてコンポーネント定義用のtclをパッケージすると、ツール上からドロップインでコンポーネントをインスタンスできるようになります。
また、その際にメモリバスであればアドレスセレクタやバス幅変換・バーストサイクル制御やアービトレーションを、データストリームであればストリーム律速やクロックドメインブリッジなど、手作業では大変面倒くさい上に検証も大変な部分を全自動で生成してくれます。

特にメモリバス制御の恩恵は大きく、従来は外部メモリ等を利用するシステムの設計はコントローラやデバイスの物理仕様が密接に関わって大変だったのですが、Avalonインターフェースを使うことで完全にメモリを抽象化して設計できるようになります。

今回はこのうちメモリバス仕様であるAvalon-MMインターフェースの部分(のさらにバースト時の挙動)に絞って説明をします。
それ以外の仔細については末尾に仕様書へのリンク貼りましたのでそちらを参照してください。


・Avalon-MM バーストライトの動作
avmm_burstwrite.png
図は5ワードバーストの書き込みの例です。いきなりプリミティブな話になりますが、先に進みます。

・0クロック目
リセット後の最初のトランザクションは必ずwriteがネゲートの状態から始めます。このときwaitrepuestの状態は未定義です。

・2クロック目
writeをアサートしてバーストライトをリクエストします。addressにはバースト先頭アドレス、burstcountにはトランザクションのライトデータ数、writedataとbyteenableには最初のデータワードをセットします。
リクエストが受理されたかどうかはwaitrequestの状態を監視します。もしwaitrequestがアサートされていた場合は、ネゲートされるまで状態を保持しなければなりません。

・5クロック目
この例ではここでwaitrequestがネゲートされ、Avalonコネクター側にバーストライトが許可されました。このタイミングでアドレスとバースト数がコネクター側に通知され、以降はリクエストしたワードの数だけwriteを繰り返すことになります。

・8クロック目
バーストトランザクション中はwriteをネゲートしてコネクター側を待たせることができます。
ただし、この状態はコネクター側のアービトレーションがストールするので、もし同じスレーブにアクセスする別のマスターがあった場合、そちらもストールしたままになります。バス仕様効率の観点からトランザクション中にマスター側からストールさせるのは極力避けるべきです。

・10クロック目
バーストライト中でもwaitrequestがアサートされた場合はネゲートまで状態を保持しなければなりません。この例では3クロック分アサートされていますが、実際には何処に幾つのwaitrequestが入るのかはわかりません。

・13クロック目
最後のデータワードがコネクター側に取り込まれるとトランザクションが終了となります。引き続いて次のバーストライトトランザクションを行う場合はwriteをアサートしたままにできます。
終了通知信号はないので、マスター側とコネクター側でデータの数がずれた場合はトランザクションがスリップしたまま進行してしまいます。大抵はバスロックになります。バスの信号でトランザクションアボートはできないため、一端バスロックしてしまった場合はリセットが必要です。

以上がバーストライトのトランザクションです。


・Avalon-MM バーストリードの動作
avmm_burstread.png
バーストリード側も5バーストリードを例とします。

・0クロック目
リセット後の最初のトランザクションは必ずreadがネゲートの状態から始めます。このときwaitrepuestの状態は未定義です。ただしreaddatavalidはネゲートの状態になります。

・2クロック目
readをアサートしてバーストリードをリクエストします。addressにはバースト先頭アドレス、burstcountにはトランザクションのリードデータ数を指定します。
byteenableはリードのみのマスターでは不要の信号です。リード・ライトマスターの場合、byteenableは全ビット1を指示しておく必要があります。この例では32bitバスを想定しているため、byteenableは4bit幅の信号となっています。
リクエストが受理されたかどうかはwaitrequestの状態を監視します。もしwaitrequestがアサートされていた場合は、ネゲートされるまで状態を保持しなければなりません。

・5クロック目
この例ではここでwaitrequestがネゲートされ、Avalonコネクター側からバーストリードが許可されました。このタイミングでアドレスとバースト数がコネクター側に通知され、マスターはreadをネゲートします。引き続いて次のバーストリードをリクエストしたい場合はreadをアサートしたままにできます。
以降はリクエストしたワードの数だけデータが送られてくることになります。

・8,9,11,12クロック目
リードデータはトランザクション開始後、任意のタイミングでコネクター側から転送されてきます。マスター側ではreaddatavalidの状態を監視して、この信号がアサートされたときのreaddataを取り込みます。
この例では2クロック空き、2ワード毎の転送となっていますが実際には読み出すスレーブの動作やバス幅により変わります。
マスター側からはデータが転送されてくるのを待たせることはできないため、バーストデータ数を受け入れることが可能な状態でトランザクションを発行しなければなりません。

・14クロック目
最後のデータが送られてくるとトランザクションは終了となります。
バーストライトと同様に終了通知信号はないので、リクエストした数と送られてきた数を数えてトランザクションの終了を判断することになります。これもバス信号からトランザクションアボートはできないため、バスロックした場合は復帰にリセットが必要です。

以上がバーストリードのトランザクションになります。
なお、バーストリードの場合はトランザクションリクエスト(read信号)とデータ転送(readdataおよびreaddatavalid)が分かれているため、全データが転送されるまえに次のリードリクエストを発行することも可能です。


・Avalon-MM 20.1でのバースト時のbyteenableの仕様

ここからはAvalon-MMのbyteenable信号の話です。
byteenable信号は8ビットを超えるバス幅での転送中に、1つ以上の任意のバイトレーンを有効にできます。byteenableの各ビットは、writedataおよびreaddataのバイトに対応しています。

byteenable信号はその名前の通りトランザクション中にデータバスのバイトレーンの有効・無効を示す信号で、ほとんどはライト動作の時に書き戻すバイトレーンを指示するために使われます。
リード時にはそのバイトレーンがを読み出すかどうかの指示に使う事もできますが、現在インテルではこのような動作は非推奨としていて、スレーブ側ではbyteenableの状態によって副次作用を起こさない(つまりバイトレーン単位での読み出し破壊のない)実装を推奨としています。

ライト時、マスター側のbyteenableのビットnはワード中のバイトnが書き込まれるかどうかを示します。
例えば32bitマスターが64bitスレーブにバイトアドレス4からバースト書き込みを行う場合、スレーブによって認識される最初の書き込み転送はアドレス0に対してbyteenable=8'b11110000となります。
byteenable信号はバーストの各ワードごとに変更でき、byteenableがアサートされていないバイトの書き込みはスレーブ側で無視されます。byteenable信号がすべて0のデータは書き込まれることはありませんが、スレーブ側へはライトコマンドが通知されます。
またbyteenable信号の機能は、バーストライトと非バーストライトでは同じになります。

一方でリード時はbyteenableの動作はやや特殊なものになります。
Avalonインターコネクトがマスターとスレーブの間に挟まる場合(PlatformDesignerを使うと大抵はこうなる)、インターコネクトはマスターからスレーブに送信されるリードコマンドを抑制するように動きます。
例えば、マスターがbyteenable信号がすべて0のリードコマンドを送信すると、インターコネクトがトランザクションを抑制してしまいます。その結果スレーブはリードコマンドに応答せず、マスターへは不定値がリードデータとして返されます。
バーストカウントが1以上のリードの場合、byteenableはすべてアサートしておく必要があります。

なおリードでもライトでも、インターフェースにbyteenable信号ポートがない場合はすべてのbyteenable信号がアサートされているとみなして転送が行われます。


・資料

・Avalon[レジスタードトレードマーク] Interface Specifications(v20.1)
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/mnl_avalon_spec.pdf

・Avalonインタフェースの仕様書(v15.1の和訳)
https://www.intel.co.jp/content/www/jp/ja/programmable/documentation/nik1412467993397.html

・自作のPlatformDesigner用コンポーネント群
https://github.com/osafune/peridot_peripherals

Tang-NANO届いた(追記あり) [FPGA]

SiPeedの激安FPGAボード、Tang-NANOがSeeedで販売になってたのでいくつかまとめて購入しました。
EIG1WxvUUAABb7M.jpg

GOWINのツールは半年ぐらい前からインストールして触っていたのですが、現物含めたファーストインプレッションとしては‥‥

・GOWIN IDEツール
意外と使いやすい。SynplifyProで論理合成から配置配線までやるので、IDEはほぼガワだけの存在。そのうちVScodeのプラグインが出てきそう。
コンパイルはかなり高速だけどチューニング項目はあんまりない。タイミングを追い込んで使うようなヘビーな使い方を期待すると死ぬ。
ハードマクロを使うIPジェネレータや、組み込みロジアナなんかも一通り揃っている。
ただし、論理シミュレータがまったくないので、これだけで使おうとすると泥沼。QuartusPrime Liteと併用してModelSimを使うのが吉。

・Tang-NANOボード
使われているFPGAはGW1Nシリーズの一番小さいやつ。1152LUT+864FFで乗算器はなし。メモリマクロは18kbitのブロックRAMが4個。PLLが1個。コンフィグROMを内蔵しているので、MAX10の500~800LE相当な感じ。
オンボードにはJTAGダウンローダが載っているので、単体でGOWIN IDEのProgrammerからコンフィグレーションデータを書き込むことができる。
それ以外には64MbitのQSPI-SRAMが載ってる。所謂IoT-RAMと呼ばれているグループで、小ピン(6本)でそこそこ高速な大容量メモリを扱える。
ボード上には40ピンFPCも載っていて、4.3インチグラフィック液晶のデファクトスタンダード配置。専用の800x480 LCDの他、秋月で売ってる480x272 LCDも接続できる。

なかなかいい、と思いきやLCDバックライト昇圧回路が問題でした。

サンプルのコンフィグで指定のLCDを繋ぐとカラーバーは出る、しかしLCDを繋いでないときは点滅し続けるカラーLEDがLCDを繋いでいるときは途中で止まってしまう。しばらくほっとくとまた点滅を始める。
USBの電源供給の問題かと思ったので5V/2Aの充電器に繋いでみるも、やっぱり挙動は変わらない。
個体の問題かと思って別のボードを繋いで見ても同じ症状がでる。

こういう不可解な挙動をする場合、かなり高い確率でFPGAの電源系に問題を抱えています。
サージやドロップで部分的に内部ロジックの動作がおかしくなり、CRCチェックが回ってくると再コンフィグして復帰する、というパターン。

それでパターンを追いかけてみると、1.2Vの電源が1本、昇圧DC/DCのインダクタのそばを通り、ICの下をくぐってバックライトLEDラインと並走して、かなり大回りしてFPGAに接続されているのがわかりました。
また1.2V/3,3V LDOへの入力も昇圧用インダクタと十分なデカップリングがされていないので、1.2Vラインの電源品質はかなり悪いと考えられます。

tangnano_power.jpg

基板のアートワークレベルの問題で、部品の載せ替え程度では解決しそうにないので、LCDを使う場合はオン
ボードのバックライト昇圧回路は切り離して、外部にバックライト電源を接続する必要がありそうです。
なんとか電源パターンのカット&ジャンパでどうにかできないか模索中。

で、とりあえずLチカ




追記。
SiPeedからレスがあり、どうも出荷で書き込まれてるやつはタイミングmetに不具合があるようです。

sipeedio.png

さらに迅速にストレステストを実施してもらい、1.2Vの安定性を確認していただきました。



ただ、出力しかしないはずのLCDを接続するとおかしくなるのも、負荷のかかり方でシビアなタイミングの問題でてるとするならやはりボードなりデバイスなり電源まわりに弱い箇所があるのだろうとは思います。
上限を見極めたいので、こちらでももうちょっと調べています。


さらに追記。

1.2Vラインをジャンパして昇圧DC/DCをカットしたものと、無改造のものを比較測定しました。
接続したLCDは秋月のATM0430D5です。これに480x272のカラーパターンを表示させて電源ラインに重畳するノイズを見ました。



昇圧DC/DCの1.5MHzのノイズが定常で±60mV以上重畳していて、動作マージンはかなり厳しいと考えられます。タイミングぎりぎりのデザインはやらない方がいいですね。

MakerFaire深圳と深圳見学会(その1)

今年は11月9~10日の日程で行われたMakerFaire深圳を(ようやく)見に行ってきました。
DSC_2309.JPG
例年MakerFaire台北と時期が近く、なかなかスケジュールの都合が取れなかったのですがようやく行くことが出来ました。なにげに初の中国本土です。

深圳への入国ルートはいくつかありますが、今回は香港空港→MRT上水駅まで高速バス、上水から落馬洲へMRTで移動して、福田口岸のイミグレを通るルートにしました。
理由はいくつかありますが、落馬洲-福田は両方ともMRTの駅と直結なので迷わずに済みそうなのと、行きはMakerFaire会場へ直接行くので留仙洞駅への乗り換えが少ないのがいいのが主なところです。

毎年会場が変わっていくMakerFaire深圳ですが、今年の会場はスタートアップ向けのオフィスを整備している区画に隣接した半地下の施設でした。雰囲気的にはMakerFaire京都の会場に近いですかね。
DSC_2311.JPG
DSC_2312.JPG

会場の裏手ではがんがんビルが生えていってます。
DSC_2321.JPG

教育面の展示が多いのはアジア圏のMakerFairに共通してるシーンですね。
DSC_2313.JPG

日本出展勢のブースはNTと変わらない顔ぶれ。
DSC_2315.JPG

MakerFaire深圳はここ毎年のように開催地が変わっていて、少し前は大規模な開催で賑わっていましたが、今年の会場は比較的こぢんまりしていて、一頃のMakerムーブメントも落ち着いてきたのかなという印象を受けました。
とはいえ、会場の裏手では大規模なMakerスタートアップ向けのオフィスビルが造成されている最中で、ビジネスとして広げていこうという気合いを感じます。

そのままMakerFaire会場を後にして、華強北の電子部品ビルへ向かいます。
DSC_2331.JPG
当日は日曜だったので大半の店舗が閉まっていたのですが、行ってみて確信しました。
ここ秋葉原じゃなくてデジットが無限に広がった五階百貨店だ!

日が落ちると至る所でLEDディスプレイが輝き始めます。
DSC_2337.JPG
このシーンは我々が80年代に夢見たSFサイバーパンク!


変わって二日目はスイッチサイエンスの高須さん(@tks)主催の東莞工場見学ツアーに行きました。
(つづく)


前の5件 | -