So-net無料ブログ作成

AXIの勉強(その2.2) [AXI]

書き込みの依存関係です。
3チャンネルあるので長くなりますが、読み込みと同じように分けてみます。

Write transaction dependencies
Image 066.png

1• the master must not wait for the slave to assert AWREADY or WREADY before asserting AWVALID or WVALID
2• the slave can wait for AWVALID or WVALID, or both before asserting AWREADY
3• the slave can assert AWREADY before AWVALID or WVALID, or both, are asserted
4• the slave can wait for AWVALID or WVALID, or both, before asserting WREADY
5• the slave can assert WREADY before AWVALID or WVALID, or both, are asserted

実はAWとWの2チャンネルの依存関係が絡んでるここが結構面倒です。

1 マスターのAWVALIDやWVALIDは、AWREADYとWREADYに依存してはならない。
2,3 スレーブのAWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。
4,5 スレーブのWREADYは、AWVALIDかWVALID、もしくは両方に依存しても、しなくても良い。

「1」の制約は
・AWシーケンサーはAW自身のREADYだけでなく、WのREADYも参照してはならない
・WシーケンサーはW自身のREADYだけでなく、AWのREADYも参照してはならない
という2つの制約になっています。

なぜか。
書き込みなのでマスターのAWとWはソースですが、AWとWの順番には特に決まりはなく、アドレスが先でそれからデータ、先にデータを出してからアドレスを送る、もしくは同時、でかまいません。
・ マスターはAWとW、どちらを先に出すか、自由に選べる
・ スレーブはAWとW、どちらを先に受け取るか、自由に選べる
という状況です。相手がどちらを先だと想定しているのかが不明です。

この状態で、
・ もしマスターのWVALIDがAWREADYに依存していて (これが違反)
・ マスターはAW→Wの順番で送る
・ スレーブはW→AWの順番で来ると思ってる
という場合、マスターがAWREADY待ち、スレーブがWVALID待ち、となりデッドロックします。

普通アドレスが先でデータが後でしょう、って事で
AWVALID <= '1';
if (AWREADY = '1') then
 AWVALID <= '0'; next_state;
WVALID <= '1';
if (WREADY = '1') then
 WVALID <= '0'; next_state;

こんなマスター回路が思いつきます。当たり前な回路に見えますが、 WVALIDがAWREADYに依存しているので、実はこれ違反です。ただ、世の中、アドレスが先だと想定してるスレーブがほとんどなので、大体問題なくつながっちゃいます。
データが来るまでアドレスは受け付けない、というひねくれた(けど仕様に反してはいない)スレーブが、この回路につながるとデッドロックします。例えばこんな回路。
if (WVALID = '1') then
 WREADY <= '1';
 AWREADY <= '1';  データが送られ始めてからアドレスを受け取る

AWVALIDかWVALIDを動作開始のトリガーと考えると、そんなにひねくれて見えませんよね。2,3,4,5の項目から、これは正しい動作です。


この制約は多分、アドレスとデータを同時に転送できるようにするために作られたんだと思います。データを先に転送するような回路は、もちろん作っても良いですけど、不自然ですよね。

2,3,4,5の制約は、今までと同じく、VALID側を制約して、READY側は自由にすし、デッドロックを回避する、という項目です。


6• the slave must wait for both WVALID and WREADY to be asserted before asserting BVALID the slave must also wait for WLAST to be asserted before asserting BVALID, because the write response, BRESP, must be signaled only after the last data transfer of a write transaction

ちょっと長めですが、要するに
・全てのデータ転送を終えてから、BVALIDをアサートすること。
という制約です。リードのAR→Rの制約と似ています。

注意点としてはWLASTも見ている所です。今まではペイロードの中身がタイミングに影響することはなかったのですが、「全ての」が関係してきます。AXIはバースト転送が基本なので、Wチャンネルの転送が何回あるかはペイロードの中身を見ないとわかりません(転送が1回でも1バーストです)。WREADY&WVALID&WLASTが揃ったのを確認してから、BVALIDをアサート、レスポンスのステートに入ります。


7• the slave must not wait for the master to assert BREADY before asserting BVALID
8• the master can wait for BVALID before asserting BREADY
9• the master can assert BREADY before BVALID is asserted.

これは単純。Bチャンネルのデッドロック防止です。


AXI4になると書き込みの依存関係の図に、矢印が2本増えます。
Image 067.png

項目はほとんど同じですが、、「6」だけ異なります。
• the slave must wait for AWVALID, AWREADY, WVALID, and WREADY to be asserted before asserting BVALID
the slave must also wait for WLAST to be asserted before asserting BVALID because the write response, BRESP must be signaled only after the last data transfer of a write transaction

これは
・アドレス転送と、全てのデータ転送を終えてから、BVALIDをアサートすること。
という内容になります。アドレス転送が条件に入ってます。

実はAXI3だと、アドレス転送を完了させないままレスポンスを返せるようになってます。制約がありませんので。AWREADYをずっと返さずにデータ転送を終えて、レスポンスを返して、それからアドレス転送を完了する、という順番でも良かったわけです。
まぁ、普通に考えればおかしな動作ですが。制約されてない以上、あり得る動作です。

AXI4ではこれが制約され、マスターがアドレスとデータ全ての転送を完了するまで、スレーブはレスポンスを返せなくなってます。

スレーブ側の制約です。AXI3のスレーブをAXI4のマスターに接続するときに注意が必要で、ペイロードの内容を変換する以外に、この書き込みの依存関係を満足させる必要があります。

nice!(0)  コメント(0)  トラックバック(0) 

nice! 0

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

Facebook コメント

トラックバック 0

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

×

この広告は1年以上新しい記事の更新がないブログに表示されております。