A checklist of AXI pitfalls for FPGA engineers points to the same place: most board-level hangs don't come from not recognizing AWVALID or WREADY, but from treating five independent channels as one sequential pipeline. Simulation passes and the board stalls, often in the few wait cycles after VALID goes high.
The source material divides AXI interfaces in FPGA development into three types: AXI4-Full targets high-performance memory access, supports burst transfers, transaction IDs, and multiple outstanding transactions, and is used for DDR access and DMA movement; AXI4-Lite does not support bursts or transaction IDs and is typically used for CPU access to FPGA internal registers; AXI4-Stream has no address channel and transfers data as a stream, used for video, ADC capture, and high-speed network data paths. The three are not a full version, a slimmed-down version, and a special version; they are divided by data-interaction scenario. Wrapping a simple register module in AXI4-Full means the interface choice has already diverged from the application, and subsequent debugging cost rises accordingly.
All AXI channels use VALID/READY handshakes, and a transfer completes only when VALID and READY are both high on the same rising clock edge. The typical error given in the source material is: the Master raises AWVALID to send address 0x1000, the Slave's AWREADY stays at 0, and AWADDR as well as AWLEN, AWSIZE, and AWBURST must remain stable—the address cannot be changed to 0x1004 just because several cycles have passed. Another misunderstanding is writing the five channels as a fixed sequential flow: AW handles the write address and W handles the write data, but the protocol does not require the AW handshake to complete before W; the two can also handshake in the same clock cycle. However, AXI4 removed AXI3's WID, so write data must be transferred in the order of the corresponding write-address transactions. A more robust approach for a custom Slave is to buffer address and data separately, then match and execute them according to transaction information.
A complete write transaction has three parts: the AW channel completes the handshake for address and control information; the W channel completes the data handshake beat by beat, with the final beat marked by WLAST; after the Slave completes the write operation, it returns BRESP over the B channel and raises BVALID, which the Master accepts with BREADY. The high-frequency error identified in the source material is treating a successful WLAST handshake as the end of the entire write operation—WLAST only indicates the end of data transfer for the current write burst, and the transaction still needs the B-channel response to close out. When BVALID is slow to appear, check back on whether WLAST appeared in the correct position. This means that when debugging the write path, the B channel cannot be treated as an ignorable tail.
For engineers in China building boards and custom IP, the value of this checklist is not in the signal table but in the check items for self-written AXI Master/Slave: separating address and data buffers, closing out the B channel, and holding the payload after VALID goes high are all things that can be self-checked at the RTL stage. The source material does not cover specific devices, tool versions, or domestic replacement solutions, so it has no direct bearing on the supply chain or toolchain; what can be put into practice is writing the selection rationale for AXI4-Full, AXI4-Lite, and AXI4-Stream into design reviews, reducing the cases where channel-semantics errors are discovered only after board bring-up.