二つは同じものの置き方違い

対応を並べると次のようになります。

AXI の valid/ready は、EN/RDY の接続ルールにあった AND を両端の内側に移し、EN の線を消したものです。逆に言えば EN/RDY は、両端が持つはずの AND を一か所に集め、その結果を配ることで、二者を超えた合意と衝突の調停を可能にしたものです。

ここで ready という語に注意が要ります。二つの流儀で同じ語が違う意味を持っています。

BSV の RDY は報告です。「呼んでよい状態にある」と上位に知らせるだけで、それ自体は何も起こしません。呼ぶかどうかは上位のルールが決め、RDY が立っていても呼ばれないサイクルは普通にあります。送り手も受け手も同じ形で RDY を出し、両端は対称です。

AXI の ready は決定です。受け手だけが出し、送り手は上位の許可を待たずに valid で勝手に送り、受け手が ready を立てたサイクルで転送が完了します。ready は「受け取れる」という報告であると同時に「このサイクルで受け取る」という受理の決定でもあり、送り手側には ready がなく、対になるのは valid です。

対応表の一行目と二行目がその翻訳です。BSV の受け手の RDY が AXI の ready に当たり、BSV の送り手の RDY は AXI では valid と呼ばれます。BSV で ready と言えば両端が上位に出す報告、AXI で ready と言えば受け手が下す決定、と読み分けてください。

比較

使い分けは、誰が両端を見渡せるかで決まります。一つの設計の内側では、bscが全てのモジュールを見渡せるので EN/RDY が有利です。複数のメソッドを一度に呼ぶルールが書け、衝突はbscが解き、規約違反は生成物に入りません。設計の境界では、相手の中身が見えないので valid/ready が有利です。両端が自己完結し、間は配線だけで、途中にレジスタスライスを挟んでも両端の設計は変わりません。

BSV で AXI を設計するときの基本方針

ここまでの内容を設計方針として言い直すと一つの文になります。IP の境界は AXI で切り、内側は EN/RDY で書いてbscに任せる、です。

境界とは、両側を別々の人や別々のツールが作る場所のことです。他社 IP との接続、Vivado の block design に置く単位、別々に検証する単位、将来切り離して再利用する単位が境界です。そこでは相手の中身が見えないので、両端が自己完結する valid/ready を使います。BSV 側では、境界のモジュールに synthesize を付け、インタフェースのメソッドを always_ready と always_enabled にして、ポートを素の AXI 信号にします。bsc-contrib のトランザクタはこの境界の定型です。

境界の内側では、モジュールを synthesize で分けても EN/RDY のままで構いません。分けたモジュールの親も BSV であれば、親の中の接続ルールが AND を計算し、bscが両端を見渡しています。EN/RDY が使える範囲は、モジュールの大きさではなく、親をbscが見ているかどうかで決まります。

今回の AxiRegs はこの方針で書かれています。境界には xactor があり、外から見ると素の AXI4-Lite スレーブです。内側の書き込み処理は次の一つの action です。

   Stmt wrseq = seq
      while (True) action
         let a <- pop_o (xactor.o_wr_addr);
         let d <- pop_o (xactor.o_wr_data);
         if (inRange (a.awaddr)) begin
            regs [index (a.awaddr)] <= merge (regs [index (a.awaddr)], d.wdata, d.wstrb);
            xactor.i_wr_resp.enq (AXI4L_Wr_Resp { bresp: AXI4L_OKAY, buser: ? });
         end
         else
            xactor.i_wr_resp.enq (AXI4L_Wr_Resp { bresp: AXI4L_SLVERR, buser: ? });
      endaction
   endseq;
   mkAutoFSM (wrseq);

この action は AW の FIFO から1件、W の FIFO から1件を取り、B の FIFO に1件を入れます。三つの FIFO の RDY が全て立ったサイクルにだけ発火し、発火すれば三つが同時に起こります。AW と W が揃うまで待つ、B が満杯なら待つ、という制御はどこにも書かれていません。三つの RDY の AND をbscが作っているからです。

なぜ BSV の内側を AXI で書かないのか

内側も AXI で統一したほうが一貫している、という考え方は一見正しそうです。しかし、ここでそれを避ける理由は、valid/ready を内側に持ち込むと、bscがやっている三つの仕事を、それぞれ別の IP や別の道具に置き換えて加えなければいけないからです。比較表の三者以上の同時性、衝突の調停、規約の検査の三行がそれです。

三者以上の同時性について：上の wrseq は AW と W と B の三つの FIFO を一つの action で扱い、三つの RDY の AND をbscが作っています。AXI 流では AW と W は独立したチャネルなので、両方が揃ったことを判定して一つの書き込みにまとめる論理を自分で書きます。Xilinx の IP カタログにこの部分を担う汎用の IP はなく、スレーブを書く人がそれぞれのスレーブの中に同じ論理を繰り返し書いています。チャネルが増えれば AND と保持の論理が増え、ルールの原子性という BSV の主要な利点を捨てることになります。

衝突の調停について：二つのルールが同じスレーブを使おうとするとき、EN/RDY ではbscが優先順位を決めて EN に畳み込み、設計者は何も足しません。AXI 流では複数のマスタが一つのスレーブに向かう場合、AXI Interconnect や AXI Crossbar といった調停の IP を別に置きます。その IP はレイテンシを数サイクル足し、面積を消費し、優先順位や ID の幅といった設定項目を持ち、設計の一部として管理する対象になります。BSV の内側なら、調停はbscの出力の一部であり、設定も管理も要りません。

規約の検査について：EN/RDY では、RDY の立っていないメソッドを呼ぶルールは発火しないので、規約違反は生成物に入らず、検査はコンパイル時に終わっています。AXI 流では valid を ready まで保持しているか、その間データを変えていないか、といった規約はbscにとってただの 1 ビットの値の推移で、検査の対象になりません。そこでシミュレーションに AXI Protocol Checker や AXI VIP といった検証用 IP を置き、アサーションで規約違反を捕まえます。検査はシミュレーションで走らせた範囲に限られ、走らせなかった場面の違反は残ります。

まとめると、内側を AXI 流にすると、bscが無償で作っていた結合、調停、検査を、手書きの結合論理、Interconnect IP、Protocol Checker IP として設計に足し、それぞれのレイテンシ、面積、設定、検証範囲を自分で持つことになります。

内側で BSV流EN/RDY を使う理由はこの三つをbscに任せるためであり、一方、境界でAXI流 valid/ready を使う理由は相手を選ばないためです。

前のブログ 次のブログ