外部からPlatformDesignerモジュールにアクセスしよう [Platform Designer]
インテル Advent Calendar 2022 の2日目担当で、今年もPlatform Designerの記事をを書きました。そろそろPlatform Designer記事担当が定着してきた感ある。
外部からPlatformDesignerモジュールにアクセスしよう～Avalon-MMブリッジの使い方あれこれ
【時候の話】
突然寒くなりましたね。
それはそうと今年もMAX10もCyclone10LPが枯渇したまま１年が経ちました。マジか。
DC/DCコンバーターICやTVSダイオードやナイロンコネクタがようやく復活してきて安心っちゃ安心ですが、TIは自動車向けが潤沢な反面、コンシューマー向けが枯渇状態なのは変わらず‥‥。
来年のアドベントカレンダーの時にはFPGAも復活してるといいなあ
外部からPlatformDesignerモジュールにアクセスしよう～Avalon-MMブリッジの使い方あれこれ
【時候の話】
突然寒くなりましたね。
それはそうと今年もMAX10もCyclone10LPが枯渇したまま１年が経ちました。マジか。
DC/DCコンバーターICやTVSダイオードやナイロンコネクタがようやく復活してきて安心っちゃ安心ですが、TIは自動車向けが潤沢な反面、コンシューマー向けが枯渇状態なのは変わらず‥‥。
来年のアドベントカレンダーの時にはFPGAも復活してるといいなあ
2022-12-02 08:54
PlatformDesignerコンポーネント作成時の自動信号マッピング [Platform Designer]
PlatformDesignerのコンポーネント作成時に、ポート名に特定のプリフィクスを付けておくことで対応するインターフェースにマッピングしてくれる補助機能がある。
ただ万能でもなくて、AXI-Streamのアサインがないとか、リセットはcsiプリフィクスでクロックとまとめないと推論ができないとかある。まあ若干手間が減る程度。あとHDL書くときに混乱しないメリット。
そのプリフィクス名の一覧メモ
asi : Avalon-ST sink (ストリーム入力)
aso : Avalon-ST source (ストリーム出力)
avm : Avalon-MM Host (バスマスター)
avs : Avalon-MM Agent (メモリスレーブ)
axm : AXI Host (バスマスター)
axs : AXI Agent (メモリスレーブ)
apm : APB Host (AMBA マスター)
aps : APB Peripheral (AMBA ペリフェラル)
coe : Conduit (任意信号)
csi : Clock sink (クロック入力)
cso : Clock source (クロック出力)
inr : Interrupt receiver (割り込み受け取り)
ins : Interrupt sender (割り込み通知)
ncm : NiosII custom instruction Host (カスタム命令駆動)
ncs : NiosII custom instruction Agent (カスタム命令受動)
rsi : Reset sink (リセット入力)
rso : Reset source (リセット出力)
tcm : Avalon-TC Host (Avalon-MM トライステートコントローラーマスター)
tcs : Avalon-TC Agent (Avalon-MM トライステートコントローラースレーブ)
ただ万能でもなくて、AXI-Streamのアサインがないとか、リセットはcsiプリフィクスでクロックとまとめないと推論ができないとかある。まあ若干手間が減る程度。あとHDL書くときに混乱しないメリット。
そのプリフィクス名の一覧メモ
asi : Avalon-ST sink (ストリーム入力)
aso : Avalon-ST source (ストリーム出力)
avm : Avalon-MM Host (バスマスター)
avs : Avalon-MM Agent (メモリスレーブ)
axm : AXI Host (バスマスター)
axs : AXI Agent (メモリスレーブ)
apm : APB Host (AMBA マスター)
aps : APB Peripheral (AMBA ペリフェラル)
coe : Conduit (任意信号)
csi : Clock sink (クロック入力)
cso : Clock source (クロック出力)
inr : Interrupt receiver (割り込み受け取り)
ins : Interrupt sender (割り込み通知)
ncm : NiosII custom instruction Host (カスタム命令駆動)
ncs : NiosII custom instruction Agent (カスタム命令受動)
rsi : Reset sink (リセット入力)
rso : Reset source (リセット出力)
tcm : Avalon-TC Host (Avalon-MM トライステートコントローラーマスター)
tcs : Avalon-TC Agent (Avalon-MM トライステートコントローラースレーブ)
2022-09-19 00:37
マイPlatform Designerコンポーネントを作ろう [Platform Designer]
インテルFPGA Advent Calendar 2021 の2日目担当で、今年はPlatform Designerコンポーネントの定義Tclファイルについて記事を書きました。
マイPlatform Designerコンポーネントを作ろう
【時候の話】
いやマジでMAX10もCyclone10LPも、DC/DCコンバーターICもPOLモジュールもSBDもTVSダイオードも電界コンデンサもナイロンコネクタも手に入んなくてどうすんのコレ。
一時期に手に入らないって騒いでたMLCCだけが潤沢にある。
マイPlatform Designerコンポーネントを作ろう
【時候の話】
いやマジでMAX10もCyclone10LPも、DC/DCコンバーターICもPOLモジュールもSBDもTVSダイオードも電界コンデンサもナイロンコネクタも手に入んなくてどうすんのコレ。
一時期に手に入らないって騒いでたMLCCだけが潤沢にある。
2021-12-02 16:31
On-Chip Memoryの初期値ファイル [Platform Designer]
Platform DesginerのOn-Chip Memoryペリフェラルで初期値ファイル（HEXまたはMIF）を設定する場合、右のファイルボックスから選択すると絶対パスになってしまい再配布がめんどうになる。
そこで初期化ファイルをプロジェクト相対パスで指定する方法を２つ紹介。
１．相対パスを記入
Platform Designerのコンポーネントはプロジェクトルートをカレントとするので、プロジェクトフォルダ以下の相対パスをそのまま指定すればいい。
ただしLinux環境では ./～ で記入しないと認識されないことがある様子。
２．プロジェクトルートに配置
QuartusPrimeの機能として、プロジェクトルートにあるファイルは暗黙的にプロジェクトに追加されたファイルと見なすので、ファイル名のみ記述して本体をプロジェクトルートに置く。
ブートローダーみたいなファイルはこちらの方が運用が楽。
どちらの方法をとる場合でも、初期化ファイルが認識できないとQuartusはCritical Warningを報告する。
ちなみにメモリに対して初期化データの要素が足りない場合も同様にCritital Warningを出す。
ファイルが無い場合はメモリは全て0でフィルされ、足りない場合は未定義部分が0でフィルされる。
そこで初期化ファイルをプロジェクト相対パスで指定する方法を２つ紹介。
１．相対パスを記入
Platform Designerのコンポーネントはプロジェクトルートをカレントとするので、プロジェクトフォルダ以下の相対パスをそのまま指定すればいい。
ただしLinux環境では ./～ で記入しないと認識されないことがある様子。
２．プロジェクトルートに配置
QuartusPrimeの機能として、プロジェクトルートにあるファイルは暗黙的にプロジェクトに追加されたファイルと見なすので、ファイル名のみ記述して本体をプロジェクトルートに置く。
ブートローダーみたいなファイルはこちらの方が運用が楽。
どちらの方法をとる場合でも、初期化ファイルが認識できないとQuartusはCritical Warningを報告する。
ちなみにメモリに対して初期化データの要素が足りない場合も同様にCritital Warningを出す。
ファイルが無い場合はメモリは全て0でフィルされ、足りない場合は未定義部分が0でフィルされる。
2020-12-20 07:06
Avalon-MMバーストマスタのbyteenable信号 [Platform Designer]
ずいぶんと偏った項目ではあるけれども、自分自身がちょっと勘違いして覚えていた部分があったので改めてAvalon仕様書 20.1でどうなっているのかを確認してみた。
・Avalonインターフェースとは
改めて説明する必要があるかどうかはさておき、AvalonインターフェースというのはIntel FPGAのIPコアで使われるメモリバスおよびデータストリームの規格です。
これはQuartusPrimeのツール群であるPlatformDesigner（旧Qsys、もっと古くはSoPC Builder）でコンポーネント間の接続インターフェースとして定義され、この規格に則った動作をするHDLに加えてコンポーネント定義用のtclをパッケージすると、ツール上からドロップインでコンポーネントをインスタンスできるようになります。
また、その際にメモリバスであればアドレスセレクタやバス幅変換・バーストサイクル制御やアービトレーションを、データストリームであればストリーム律速やクロックドメインブリッジなど、手作業では大変面倒くさい上に検証も大変な部分を全自動で生成してくれます。
特にメモリバス制御の恩恵は大きく、従来は外部メモリ等を利用するシステムの設計はコントローラやデバイスの物理仕様が密接に関わって大変だったのですが、Avalonインターフェースを使うことで完全にメモリを抽象化して設計できるようになります。
今回はこのうちメモリバス仕様であるAvalon-MMインターフェースの部分（のさらにバースト時の挙動）に絞って説明をします。
それ以外の仔細については末尾に仕様書へのリンク貼りましたのでそちらを参照してください。
・Avalon-MM バーストライトの動作
図は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 バーストリードの動作
バーストリード側も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![[レジスタードトレードマーク]](https://blog.ss-blog.jp/_images_e/219.gif)
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
・Avalonインターフェースとは
改めて説明する必要があるかどうかはさておき、AvalonインターフェースというのはIntel FPGAのIPコアで使われるメモリバスおよびデータストリームの規格です。
これはQuartusPrimeのツール群であるPlatformDesigner（旧Qsys、もっと古くはSoPC Builder）でコンポーネント間の接続インターフェースとして定義され、この規格に則った動作をするHDLに加えてコンポーネント定義用のtclをパッケージすると、ツール上からドロップインでコンポーネントをインスタンスできるようになります。
また、その際にメモリバスであればアドレスセレクタやバス幅変換・バーストサイクル制御やアービトレーションを、データストリームであればストリーム律速やクロックドメインブリッジなど、手作業では大変面倒くさい上に検証も大変な部分を全自動で生成してくれます。
特にメモリバス制御の恩恵は大きく、従来は外部メモリ等を利用するシステムの設計はコントローラやデバイスの物理仕様が密接に関わって大変だったのですが、Avalonインターフェースを使うことで完全にメモリを抽象化して設計できるようになります。
今回はこのうちメモリバス仕様であるAvalon-MMインターフェースの部分（のさらにバースト時の挙動）に絞って説明をします。
それ以外の仔細については末尾に仕様書へのリンク貼りましたのでそちらを参照してください。
・Avalon-MM バーストライトの動作
図は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 バーストリードの動作
バーストリード側も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
2020-08-15 20:56
