PeakRDL-regblock AXI-Lite prematurely asserting wready/awready when it can't handle new wdata/awdata

[arhum-alam]

The AXI-Lite code as part of PeakRDL-regblock is unable to handle the case where a new data/address write occurs before a bresp is generated for the previous data-address pair. However the wready/awready signal is asserted and is expecting new writes. This is highlighted in the waveform below where the 2nd wdata is input before the first bresp is generated:

As per the AXI-Lite documentation (https://developer.arm.com/documentation/ihi0022/hc?lang=en): "AXI4-Lite supports multiple outstanding transactions, but a Subordinate can restrict this by the appropriate use of the handshake signals" [Section B1.1.4]

[amykyta3]

The AXI4-Lite implementation is intentionally designed be lightweight and have minimal buffering storage space. In your example, wready is deasserted because it only has buffer space for one data word and is unable to process it until it has the corresponding address information for the write operation. This results in a stall cycle.
As soon as the awvalid arrives, the internal request buffer is available to accept the next transfer which appears to arrive soon after.

The delay of bvalid has nothing to do with the 2nd wvalid. Instead, this is due to the internal write processing latency of the register block - each transaction takes two clock cycles from the moment both parts arrive (wvalid and awvalid). I hope to make that latency even shorter in a future release (See #47). Your example's second transaction request just happened to finish being issued late enough that the first one was able to complete.

The register block does indeed support multiple outstanding transactions according to the AMBA spec, however there are some edge cases that prevent it from being able to effectively pipeline them. One option would be to add numerous independent FIFOs on each AXI channel to fully decouple them, but that would be quite costly for what is intended to be a lightweight implementation.