AXIの勉強（その2.1） [AXI]
続いてリードの依存関係。
Read transaction dependencies
1• the master must not wait for the slave to assert ARREADY before asserting ARVALID
2• the slave can wait for ARVALID to be asserted before it asserts ARREADY
3• the slave can assert ARREADY before ARVALID is asserted
4• the slave must wait for both ARVALID and ARREADY to be asserted before it asserts RVALID to indicate that valid data is available
5• the slave must not wait for the master to assert RREADY before asserting RVALID
6• the master can wait for RVALID to be asserted before it asserts RREADY
7• the master can assert RREADY before RVALID is asserted.
なんかいっぱいありますが、分けてみるとわかりやすいかと思います。
まず上3つ。1,2,3。
・マスターのARVALIDは、ARREADYに依存してはならない
・スレーブはARVALIDを待ってからARREADYをアサートしても良い
・スレーブはARVALIDより前にARREADYをアサートしても良い
前の記事のソース・シンクの関係と同じです。ARチャンネルのデッドロックを防止する制約です。
下3つ。5,6,7。
・スレーブのRVALIDは、RREADYに依存してはならない
・マスターはRVALIDを待ってからRREADYをアサートしても良い
・マスターはRVALIDより前にRREADYをアサートしても良い
Rチャンネルのデッドロック防止です。
真ん中の一つ。4。
・スレーブはARREADYとARVALID両方がアサートされるのを待ってからRVALIDをアサートすること
ARREADYとARVALID両方がアサートされるということは、ARの転送が完了したということです。
ARVALIDはマスターがドライブしているので、スレーブ側のRのソースシーケンサーの制約になります。つまり、
・スレーブはARVALIDが来ないうちにRVALIDをアサートしてはならない
・スレーブはARREADYを先に返してからRVALIDをアサートすること
という制約です。
要は
・アドレス情報が与えられてもいないのに余計な情報を勝手に送るな
・アドレス情報を受け取ったことを、まずマスターに知らせてから、データを返せ
という制約です。1つ目はまあ良いですよね。
2つ目、例えばスレーブがARREADYを返さずに、ARの情報をゆっくり解析する回路にしたとします。これ自体は正しい動作です。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：
・・・・
nクロック目：ARREADY <= '1';
この途中でデータを返すのを違反としています。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：RVALID <= '1'; 違反
4クロック目：if (RREADY) then ここでデッドロック
・・・・
nクロック目：ARREADY <= '1';
なぜか。
例えばこれにつながるマスターがこんな風に順番に処理する回路の場合です。あり得る回路です。
アドレス処理ステート
ARVALID <= '1';
↑クロック
if (ARREADY = '1') then ここでデッドロック
ARVALID <= '0';
データ処理ステート
if (ARVALID = '1') then
RREADY <= '1'
・マスターのARシーケンサーがARREADYを確認してからデータの受信処理を行う
・スレーブのRシーケンサーがARREADYをアサートする前にRREADYの評価を行う
この2つがつながるとデッドロックします。
実際の犯人はRREADYを評価していることで、RVALIDをアサートしたこと自体ではないですが。RVALIDを操作したということは、スレーブがデータ処理ステートに入ったことを意味します。けどマスターがアドレス処理のステートのままだと、RREADYが返ってこないかも知れません。
この、スレーブがデータ処理ステートに入ったのに、マスターがアドレス処理ステートのところで止まったまま、となるのを防ぐための制約で、マスター・スレーブともアドレス処理ステートを完了させてからデータ処理ステートに移行しましょう、そのために、スレーブはARREADYを先に返してからRVALIDをアサートすること、という決まり事です。
下のような違反の回路、AXIに慣れてないうちだと、意外と作りがちな回路です。
ARVALIDをアドレスストローブ信号、ARREADYをウェイト制御信号、と認識してるとこんな回路になります。パケット式じゃない、普通のタイミング方式のバスに慣れてる人がはまりやすいパターンです。
AXIはただのインターフェースの仕様で、どんなコーディングしてるのかわからない相手が接続されます。デッドロックのパターンを決めておかないとエラいことになります。なので、こんな制約が存在します。
Read transaction dependencies
1• the master must not wait for the slave to assert ARREADY before asserting ARVALID
2• the slave can wait for ARVALID to be asserted before it asserts ARREADY
3• the slave can assert ARREADY before ARVALID is asserted
4• the slave must wait for both ARVALID and ARREADY to be asserted before it asserts RVALID to indicate that valid data is available
5• the slave must not wait for the master to assert RREADY before asserting RVALID
6• the master can wait for RVALID to be asserted before it asserts RREADY
7• the master can assert RREADY before RVALID is asserted.
なんかいっぱいありますが、分けてみるとわかりやすいかと思います。
まず上3つ。1,2,3。
・マスターのARVALIDは、ARREADYに依存してはならない
・スレーブはARVALIDを待ってからARREADYをアサートしても良い
・スレーブはARVALIDより前にARREADYをアサートしても良い
前の記事のソース・シンクの関係と同じです。ARチャンネルのデッドロックを防止する制約です。
下3つ。5,6,7。
・スレーブのRVALIDは、RREADYに依存してはならない
・マスターはRVALIDを待ってからRREADYをアサートしても良い
・マスターはRVALIDより前にRREADYをアサートしても良い
Rチャンネルのデッドロック防止です。
真ん中の一つ。4。
・スレーブはARREADYとARVALID両方がアサートされるのを待ってからRVALIDをアサートすること
ARREADYとARVALID両方がアサートされるということは、ARの転送が完了したということです。
ARVALIDはマスターがドライブしているので、スレーブ側のRのソースシーケンサーの制約になります。つまり、
・スレーブはARVALIDが来ないうちにRVALIDをアサートしてはならない
・スレーブはARREADYを先に返してからRVALIDをアサートすること
という制約です。
要は
・アドレス情報が与えられてもいないのに余計な情報を勝手に送るな
・アドレス情報を受け取ったことを、まずマスターに知らせてから、データを返せ
という制約です。1つ目はまあ良いですよね。
2つ目、例えばスレーブがARREADYを返さずに、ARの情報をゆっくり解析する回路にしたとします。これ自体は正しい動作です。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：
・・・・
nクロック目：ARREADY <= '1';
この途中でデータを返すのを違反としています。
if (ARVALID) then
1クロック目：AR.addr評価
2クロック目：AR.length評価
3クロック目：RVALID <= '1'; 違反
4クロック目：if (RREADY) then ここでデッドロック
・・・・
nクロック目：ARREADY <= '1';
なぜか。
例えばこれにつながるマスターがこんな風に順番に処理する回路の場合です。あり得る回路です。
アドレス処理ステート
ARVALID <= '1';
↑クロック
if (ARREADY = '1') then ここでデッドロック
ARVALID <= '0';
データ処理ステート
if (ARVALID = '1') then
RREADY <= '1'
・マスターのARシーケンサーがARREADYを確認してからデータの受信処理を行う
・スレーブのRシーケンサーがARREADYをアサートする前にRREADYの評価を行う
この2つがつながるとデッドロックします。
実際の犯人はRREADYを評価していることで、RVALIDをアサートしたこと自体ではないですが。RVALIDを操作したということは、スレーブがデータ処理ステートに入ったことを意味します。けどマスターがアドレス処理のステートのままだと、RREADYが返ってこないかも知れません。
この、スレーブがデータ処理ステートに入ったのに、マスターがアドレス処理ステートのところで止まったまま、となるのを防ぐための制約で、マスター・スレーブともアドレス処理ステートを完了させてからデータ処理ステートに移行しましょう、そのために、スレーブはARREADYを先に返してからRVALIDをアサートすること、という決まり事です。
下のような違反の回路、AXIに慣れてないうちだと、意外と作りがちな回路です。
ARVALIDをアドレスストローブ信号、ARREADYをウェイト制御信号、と認識してるとこんな回路になります。パケット式じゃない、普通のタイミング方式のバスに慣れてる人がはまりやすいパターンです。
AXIはただのインターフェースの仕様で、どんなコーディングしてるのかわからない相手が接続されます。デッドロックのパターンを決めておかないとエラいことになります。なので、こんな制約が存在します。
AXIの勉強（その2） [AXI]
何年ぶりでしょう（笑）
簡単にタイミングの依存関係について書いてみます。
元になる資料はARMからダウンロードできる「IHI0022E_amba_axi_and_ace_protocol_spec.pdf」です。Issue Eが多分最新版。
AXIは、
という5チャンネルでパケットのやりとりをしている感じなのですが、それぞれのチャネルがREADYとVALIDを持っていて個別にハンドシェイクを行う、という仕組みになっています。
けど、ハンドシェイクは個別ですけど、ちょっとは相手のことも考えないとダメよ、勝手に動くとデッドロックしますよという項目です。これが依存関係で、資料に書いてあります。A.3.3のRelationships between the channelsから始まる内容です。
A3.3.1 Dependencies between channel handshake signals
一番基本になる依存関係です。5系統それぞれにある、READYとVALIDの関係です。AXI Streamにも同じ制約がかかります。こんなことが書かれてます。
• the VALID signal of the AXI interface sending information must not be dependent on the READY signal of the AXI interface receiving that information
• an AXI interface that is receiving information can wait until it detects a VALID signal before it asserts its corresponding READY signal.
掻い摘まむと
・VALIDはREADYに依存してはならない（ソース側の制約）
・READYはVALIDに依存しても良い（シンク側の制約）
と言う事になります。
（マスター・スレーブと呼ぶとと5チャンネルを束ねたインターフェースを指します。だから英語の方ではちょっと持って回った言い方になってます。間際らしいので、ここでは個々のチャンネルのインターフェースをソース・シンクと呼んでます。ソースからシンクへデータが流れます。マスターは3つのソースと2つのシンク、スレーブは3つのシンクと2つのソースを持ちます。）
要するに、ソース側のシーケンサーを作るとき、
if (READY = '1') then
VALID <= '1';
みたいな回路は作っちゃダメですよ、という制約になります。
シンク側は
if (VALID = '1') then
READY <= '1';
という回路を作っても大丈夫です。
ソース側の制約な訳ですが、ダメな回路例と大丈夫な回路例をつないでみれば一目瞭然かと。ソースがREADY待ちで、シンクがVALID待ちとなり、デッドロックします。どちらかに制約をかける必要があり、AXIではVALID側を制約しています。
ちなみにシンク側ですが、この回路にしなければなりません、という’訳ではありません。VALIDに依存しない、
if (Im_free) then
READY <= '1';
という回路にしても良いです。
VALIDに関係なく、自分の都合でREADYをアサートしてもかまいません。READY側の方が自由になっています。
こんなのがAXIの依存関係です。他のチャンネルとの依存関係も読んでいきましょう。
簡単にタイミングの依存関係について書いてみます。
元になる資料はARMからダウンロードできる「IHI0022E_amba_axi_and_ace_protocol_spec.pdf」です。Issue Eが多分最新版。
AXIは、
という5チャンネルでパケットのやりとりをしている感じなのですが、それぞれのチャネルがREADYとVALIDを持っていて個別にハンドシェイクを行う、という仕組みになっています。
けど、ハンドシェイクは個別ですけど、ちょっとは相手のことも考えないとダメよ、勝手に動くとデッドロックしますよという項目です。これが依存関係で、資料に書いてあります。A.3.3のRelationships between the channelsから始まる内容です。
A3.3.1 Dependencies between channel handshake signals
一番基本になる依存関係です。5系統それぞれにある、READYとVALIDの関係です。AXI Streamにも同じ制約がかかります。こんなことが書かれてます。
• the VALID signal of the AXI interface sending information must not be dependent on the READY signal of the AXI interface receiving that information
• an AXI interface that is receiving information can wait until it detects a VALID signal before it asserts its corresponding READY signal.
掻い摘まむと
・VALIDはREADYに依存してはならない（ソース側の制約）
・READYはVALIDに依存しても良い（シンク側の制約）
と言う事になります。
（マスター・スレーブと呼ぶとと5チャンネルを束ねたインターフェースを指します。だから英語の方ではちょっと持って回った言い方になってます。間際らしいので、ここでは個々のチャンネルのインターフェースをソース・シンクと呼んでます。ソースからシンクへデータが流れます。マスターは3つのソースと2つのシンク、スレーブは3つのシンクと2つのソースを持ちます。）
要するに、ソース側のシーケンサーを作るとき、
if (READY = '1') then
VALID <= '1';
みたいな回路は作っちゃダメですよ、という制約になります。
シンク側は
if (VALID = '1') then
READY <= '1';
という回路を作っても大丈夫です。
ソース側の制約な訳ですが、ダメな回路例と大丈夫な回路例をつないでみれば一目瞭然かと。ソースがREADY待ちで、シンクがVALID待ちとなり、デッドロックします。どちらかに制約をかける必要があり、AXIではVALID側を制約しています。
ちなみにシンク側ですが、この回路にしなければなりません、という’訳ではありません。VALIDに依存しない、
if (Im_free) then
READY <= '1';
という回路にしても良いです。
VALIDに関係なく、自分の都合でREADYをアサートしてもかまいません。READY側の方が自由になっています。
こんなのがAXIの依存関係です。他のチャンネルとの依存関係も読んでいきましょう。
