Iam designing AHB - Lite protocol for ddr interface ,
we are designing one master - one slave ahb-lite interface does we required to use HREADY_IN foe slave input and HSELX.
In which write transaction , when should we sent the response for the burst transaction should it be sent after burst is completed from master or when the data is written on to the ddr.
In read transaction, will master request the read next read data in a burst only when previous requested data is received.
for a burst to return data for ddr takes more cycles so is the response needs to be sent for each data in read transaction.
how is response sent in read burst transaction.
Please help me to clarify this doubts.
Thanks in advance
All AHB-lite "subordinate" designs must have both HREADYOUT output and an HREADY input, and an HSEL input.
Even though you are directly connecting an AHB-lite "manager" to your DDR AHB-lite "subordinate" interface, where you would presumably tie the HSEL input to 1'b1 and connect the HREADYOUT output back to the HREADY input (as well as to the manager's HREADY input), you should still design the "subordinate" interface to have a standard AHB-lite set of inputs and outputs.
All AHB-lite transfers in a burst must have a response returned, but if you only know the actual response once a burst of writes has been received by the DDR (perhaps you are buffering them up to perform one quick DDR burst access) you could give a default OKAY response to all but the last write data transfer, and then add some wait states to the final write data transfer until you know the real HRESP response required to be returned for just that final transfer.
For bursts of reads the address phase of the next transfer will overlap with the data phase of the previous transfer, so your DDR will always know what is next being requested while it performs one read. It is a pipelined bus.
And if you are again looking at bursts, the HBURST information will tell the DDR exactly how much read data will be requested (which could allow it to prefetch data from the DDR to save single access latencies), so it can just check that the next transfer is a SEQ to know the next data in the burst is required.
Again there is a response sent for every transfer in a burst (read or write), so for the read burst you could return either a default OKAY response for all but the last transfer, the same as I described for writes, or you could just return the real response for each transfer as presumably you will know this as soon as you have the HRDATA value to return.
Hopefully that covers your questions.
Hi Colin Campbell,
Thanks for the reply
1)suppose if we have 2 master - slave interface , HSELX Signal should be tied one to both hselx signals right.
2)In early burst termination we wont be knowing exactly the last transfer in such cases also we can add wait states by de-asserting the hready_out and provide the actual response right.
3)for early burst termination does master accept the error response
4)Every busy/ idle state in burst we need to send the okay response right. suppose if we encounter busy @clk 1 we can assert the okay response in the next clock right does protocal accepts the response in the same clock cycle as it mentioned zero waited response.
s)suppose in a read burst of 4, for 2nd data we have encountered a problem but data 3 or 4th data is correct should we need to send error response for 2nd data and okay response to rest of read data right
please help me to clarify the doubts.
1. I'm now slightly worried that we are not talking about the same things when you say a "master - slave interface". I was assuming that you were describing where you have a single "manager" directly connected to a single "subordinate", where there is no need for any local address decoder or multiplexors to route back responses.
Now that you are talking about "2 master - slave interface", are you still thinking of two completely independent "managers" directly connected to two independent "subordinates", with no ability for one "manager" to access both "subordinates" ?
If yes, and this is a simple 1-1 connection, as there is only one "subordinate" connected to each "manager", the "subordinate's" HSEL input can be tied high as it is the only possible target for the "manager's" transfer, and the HREADYOUT from the "subordinate is used to drive both the "subordinate's" HREADY input AND the "manager's" HREADY input.
But if there is some sort of interconnect logic between the physical "managers" on one side of the interconnect and the physical "subordinates" on the other side, I would expect the interconnect logic to provide "subordinate" gasket ports to connect your DDR "subordinate" interface to, so this gasket interface on the interconnect will have an HSEL output, an HREADYOUT input and an HREADY output to exactly match the ports on the connected "subordinate".
On the "manager" side of the interconnect, there will either be a "manager" gasket interface where there is just a single HREADY output to drive the "manager's" HREADY input (i.e. no HSEL or HREADYOUT ports), or else the interconnect interface will appear to the "manager" as a standard AHB-lite subordinate so that it can be connected to an upstream AHB-lite subsystem beside other local "subordinate" interfaces (with local address decoding to generate the required HSEL signals and MUX logic to route back the HREADYOUT, HRDATA and HRESP outputs from the connected "subordinates".
Sorry that is all getting a bit complex, but I don't want to make any assumptions about what you are actually connecting, so am trying to cover all the possibilities.
2. "Early Burst Termination (EBT)" on an AHB-lite interface between a "manager" and "subordinates" can only occur if the "subordinate" being accessed returns an ERROR response. So if your DDR "subordinate" does return an ERROR, it already knows that EBT could occur. So as EBT occurs, the "subordinate" has already returned the transfer response, so no need for any additional wait states.
However like in Q1 where there could be an interconnect structure connecting multiple "managers" to multiple "subordinates", there is a second possible cause of EBT, that being where the arbitration logic in the interconnect switches the selected "manager" source part way through a burst, so the "subordinate" then sees an unexpected EBT if a defined length burst was in progress.
The "subordinate" will be aware of the EBT if it occurs because it will see on HTRANS that the next indicated transfer type has changed to IDLE or NONSEQ, when only SEQ or BUSY would be seen while a burst was in progress, so even if your DDR is prefetching or buffering data while handling a defined length burst, it will see when that data stream ends prematurely and can discard the remaining prefetched data or write out whatever data has been buffered.
3. When a "subordinate" signals an ERROR response, it doesn't always cause EBT. The "manager" can choose to cancel the next indicated transfer address phase value to IDLE, and then go and try to fix the cause of the ERROR, but the "manager" can also choose to ignore the ERROR, and just continue with the indicate burst sequence. So your DDR "subordinate" should not assume EBT will occur if it returns an ERROR response, that decision is the "manager's" to make.
4. IDLE or BUSY address phase transfers have a mandatory data phase response of HREADY=1'b1 and HRESP=OKAY. As an IDLE or BUSY transfer does not require the "subordinate" to perform any data transfer, there is no reason for any wait states or ERROR indication to be needed.
So yes, the data phase of an IDLE or BUSY transfer will always be zero wait, and the "manager" will sample this mandatory response at the end of that single cycle data phase.
5. If the "subordinate" returns an ERROR response to the 2nd transfer of a 4-beat burst, it is up to the "subordinate" design whether it chooses to see what the responses should be to the remaining 2 transfers (if EBT has not occurred), or whether it just assumes that as soon as one transfer has failed, all remaining transfers should also receive the same ERROR response. The AHB protocol doesn't require any specific response to be returned for the remaining transfers.
Sorry, all of the above is getting a bit detailed and specific to your design, and might be getting to be more than can be easily covered on this forum.