• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 349 subscribers
  • Views 184 views
  • Users 0 members are here
Options
Related
How was your experience today?

AXI4 BVALID Specification

minji lee

Hi

I'd like to ask whether the following BVALID violates the specification when consecutive single writes.

Regarding the two cases of BVALID shown below : 

In Case1, BVALID for different BIDs is asserted high consecutively

In Case2, BVALID  is asserted one clock later for next BID.

I would like to confirm whether Case1 violates the specification.

  • 0 Arm Employee Badge

    Hi Minji,

    The short answer - both cases are legal. 

    It is allowed for the subordinate to return back-to-back write responses on consecutive cycles without inserting a bubble. In both cases, the following dependencies have also been met (section A2.3.2.1 of AXI-L)

    • The Subordinate must wait for AWVALID, AWREADY, WVALID, and WREADY to be asserted before
      asserting BVALID.
    • The Subordinate must wait for the last write data transfer before asserting BVALID. The last write data
      transfer has WLAST asserted.
      • Whilst WLAST is not shown in your diagram, I have assumed it is high for each of the WDATA transfers as AWLEN is 0 (1 beat) for each ID.
    • The Subordinate must not wait for the Manager to assert BREADY before asserting BVALID.

    Hope that helps.

    Ben

  • 0

    From a basic point of view, BVALID just means the slave has fimished handling a write and now has a response ready for the master. it doesn’t really do anything by itself until the master also raises BREADY, and once both are high, the write response is accepted and things move on... I found that thinking of it as a simple “response available” flag makes it easier to follow, rather than getting lost in the full AXI timing diagrams...