Hello,
We are using ARM Matrix IP that is acting as a Master and using our VIP as a slave.
ARM Matrix is sending a initiating a WRITE Transfer on a slave when HREADY is low, but not keeping control signals stable till HREADY becomes high.
So the questions are
1) Is slave required to drive HREADY high when there is no active transfer? Isn't it possible that slave is busy with other activities and can't accept any new address?
2) Can address phase complete without being HREADY high? Mean as shown in attached snapshot, does Slave need to sample the address in a single cycle without HREADY being high?
3) In the protocol specs it is mentioned that "address_phase can't be stretched". Can you please elaborate that? Once Master have driven valid control signals, Slave can't drive HREADY low and must accept the address?
Appreciate your quick response.
Regards,
Tushar
Hi Tushar,
Your VIP slave is violating the AHB protocol.
HREADY from a slave is driven during the data phase of a transfer, so wait states extend the data phase. As the protocol describes a pipelined bus, one data phase transfer being extended then requires the next transfer address phase to be extended, but only as a result of the wait state, it isn't the intention of the wait state.
In your waveform you can see that HREADY is taken low by the slave during your NONSEQ write transfer address phase, which is actually the data phase of the previous IDLE transfer.
It is illegal to signal wait states to an IDLE transfer because an IDLE transfer doesn't require a slave to perform any transfer, so no valid reason for that slave to then stall the bus.
So this attempt to stall the current transfer address phase fails for two reasons...
1) HREADY is driven to signal when a data phase transfer is completing, it isn't used to stall a current address phase transfer.
2) Driving HREADY low for an IDLE transfer data phase is illegal, so the master has assumed that HREADY will have been high (as the protocol states), and so has only driven the NONSEQ write transfer address phase for one cycle.
Answering your specific questions...
1) Yes. The slave might be internally busy, but the bus interface is idle at this time, so must be able to sample a new transfer when HREADY is driven high to signal a previous transfer data phase completing.
2) Not in a correctly designed system. As described, HREADY must be high for the data phase of the previous IDLE transfer, so the master has assume HREADY would be high in your example. The source of the problem is the VIP slave violating protocol, not that master's assumption that the slave would comply with protocol requirements.
3) Address phase transfers are stretched, but only as a consequence of the previous transfer data phase having wait states added. The protocol describes a pipelined bus, so stall the data phase and this requires the next transfer address phase to also be stretched, but HREADY is the slave signalling completion of the data phase of a transfer, it is not the slave's intention to stretch the next transfer address phase (which it hasn't yet sampled).
One observation, when you have driven HREADY high (presumably following the HCLK rising edge), when HREADY next goes low this is before the next HCLK rising edge, so was this wait state ever sampled by the master ?
Colin
Thanks Colin for detailed reply. That answers all questions.
The wait state is never sampled by Master as it does not wait for HREADY high for starting address phase.
Just to be clear here, the (illegal) wait state is not sampled by this master because it knows that HREADY must be high during the data phase of the preceding IDLE transfer.
The fault here is with the slave and how it drives HREADY, and not with the master's assumption that HREADY will be high.