In specification it is mentioned that WREADY signal can wait for AWVALID and WVALID signals.
Does it mean that WREADY signal should be asserted only after assertion of AWVALID and WVALID signals.
What is the relation between these signals?
and performance wise what is the best implementation?
As your quotes states, the WREADY signal "CAN" wait for AWVALID and WVALID, it doesn't state that it "MUST" wait for them. The same is also stated for the AWREADY signal.
So you could design a very simple slave that only looks at a write request when it has both the AW and W channel information available, so only accepting write data (driving WREADY high) when it sees the master signalling the address (AWVALID high) and the data (WVALID high). And similarly only accepting the write address information when both address and data are available.
The channel handshaking rules are there to avoid any deadlocks.
For example (an illegal example to prove this point) if you had a slave that (legally) only asserted AWREADY when it saw AWVALID asserted by the master, and you had a master that (illegally) only asserted AWVALID when it saw AWREADY asserted by the slave, the AW channel would be stalled because the master and slave are both waiting for the other to signal a transfer could start.
So to avoid that potential deadlock the handshaking rules state that xREADY assertion _CAN_ depend on xVALID assertion, but xVALID assertion _CANNOT_ depend on xREADY assertion on any specific channel.
(Note that there are some inter-channel dependencies which state that a VALID cannot be asserted until the READY on another channel, examples being BVALID after AWREADY/WREADY and RVALID after ARREADY, but the above handshake rule applies to VALID and READY signals on the same channel)
Regarding your performance question, that really depends on the design of the slave being written to.
If it is something like a DRAM controller where you get better performance knowing the address of the transfer long before the data transfers occur, then you would want to accept the write address as soon as it is signalled, so either driving AWREADY as soon as you sample AWVALID, or better still driving AWREADY as soon as the slave could accept an address transfer (regardless of the state of AWVALID).
A simpler slave however might need to know both the address of a transfer and the data for the transfer before it can do anything, so only driving AWREADY and WREADY high when both AWVALID and WVALID have been asserted might simplify the slave interface design, requiring less registering.
However as you are asking about AXI4-lite rather than AXI4, it is likely that you ARE looking at much simpler interfaces, rather than complex DRAM type requirements, so perhaps your slave designs wouldn't benefit from registering the AW transfer before the W transfer becomes available. Again it isn't something there is a generic "fits all" answer, it depends completely on what your design requires.
So the AXI protocol is fairly flexible here, you can choose when to accept the AW and W channel transfers when best for the slave, with the only protocol restrictions being there to avoid potential deadlocks on the channels.
Thanks Colin.
If slave asserts WREADY only after assertion of AWVALID and WVALID, it may cause deadlock situation.
Is this correct?
Whether above condition is true?
No.
When I described a deadlock I meant the master and slave each waiting for the other to do something first.
In the case you are describing, the slave is waiting for the master to assert AWVALID and WVALID, before it asserts WREADY, which is legal. This isn't a deadlock because the master CANNOT also be waiting for the slave to drive WREADY before it asserts AWVALID or WVALID.
If the master did wait for a READY input signal to be asserted before it asserted a VALID output, that would be a clear protocol violation by the master which could lead to this deadlock, but the issue there is that the master design does not comply with the protocol requirements.
Deadlocks cannot occur when the protocol requirements are followed.
Thanks a lot Colin