1

In the pc_status error bit location , is it bit #32 because in the following simulation waveform, BVALID is never asserted high during the time when pc_status error bit #32 is asserted ?

enter image description here

kevin
  • 497
  • 8
  • 25

1 Answers1

1

It's reporting the error a few cycles later. But that is the problem--at the point BVALID is asserted, AWREADY is still 0 so the write handshake isn't complete.

Justin N
  • 376
  • 1
  • 5
  • A slave must not take BVALID HIGH until after the write address handshake is complete.Or A slave must not take BVALID HIGH until after the last write data handshake is complete. <-- this explanation of pc_status[32] does not involve AWREADY !!!!!! Besides, I am using AXI slave IP from Xilinx, so it is Xilinx code that triggers bith BVALID and AWREADY – kevin Mar 17 '20 at 06:52
  • 2
    @kevin AWREADY is part of the write address handshake. – Justin N Mar 17 '20 at 06:59
  • but like I just said, it is Xilinx AXI Slave IP that triggers both BVALID and AWREADY , not my AXI master code – kevin Mar 17 '20 at 07:06
  • and there should not be any X unknown state within pc_status vector, this is something very strange – kevin Mar 17 '20 at 07:09
  • 1
    You've got some X's at the beginning of your trace. Maybe you need to reset or something. – Justin N Mar 17 '20 at 07:10
  • I extended reset for 1 more clock cycle, the X unknown states are gone now for pc_status – kevin Mar 17 '20 at 07:13
  • now I have [an entirely different pc_status issue](https://i.imgur.com/BUYqC5z.png) – kevin Mar 17 '20 at 08:14
  • You probably can't assert all of the WSTRB bits when writing to an address in the middle of the data word. Maybe the address should be incrementing by more than 1. – Justin N Mar 17 '20 at 08:19
  • can't assert all of the WSTRB bits when writing to an address in the middle of the data word. <-- is this requirement stated somewhere in the [AXI Protocol spec](https://static.docs.arm.com/ihi0022/g/IHI0022G_amba_axi_protocol_spec.pdf#page=54) ? – kevin Mar 17 '20 at 08:38
  • 1
    Yes: "The information on the low-order address lines must be consistent with the information on the byte lane strobes." – Justin N Mar 17 '20 at 08:46
  • Why **the address should be incrementing by more than 1** ? – kevin Mar 17 '20 at 09:00
  • You're writing more than one byte, so if you don't want the writes overlapping then it should increment by more than one. – Justin N Mar 17 '20 at 09:02
  • What do you exactly mean by **writes overlapping** ? – kevin Mar 17 '20 at 11:46
  • I do not see any **overlapping write** in this [simulation waveform](https://i.imgur.com/PoPzPfu.png) which has pc_status[22] bit [AXI_ERRM_WSTRB](https://www.xilinx.com/support/documentation/ip_documentation/axi_protocol_checker/v2_0/pg101-axi-protocol-checker.pdf#page=16) being asserted. – kevin Mar 17 '20 at 14:17
  • I'm getting messages about avoiding extended discussions here in comments. Maybe you should create a new question about the WSTRB error and/or the overlap. – Justin N Mar 17 '20 at 23:27
  • See https://electronics.stackexchange.com/questions/486660/axi-wstrb-and-awaddr-issue-with-overlapping-writes – kevin Mar 18 '20 at 02:14