Hello everyone!Hope ure all doing well.I've got several questions regarding the AMBA AHB specification "IHI0033C_amba_ahb_protocol_spec"1.) When is HRDATA actually valid for sampling & when is it actually driven??SCENARIO A) DRIVEN BY THE SUBORDINATE AT: the negedge of the clock inside the clock cycle of the data_phase &SAMPLED BY THE MANAGER AT: the positive edge of the clock cycle that follows right after the data_phase has finished?SCENARIO B)DRIVEN BY THE SUBORDINATE AT: the positive edge of the clock cycle after data_phase &SAMPLED BY THE MANAGER AT: combinationally or at the negedge of the clock that follows?2.) Does the same apply to HRESP and HREADY?3.) What does the specification mean by AMBA AHB being a single edge protocol? Using only the positive edge or the negative edge? but does that mean the subordinates as well or the sampling of the manager or the entirety of the SoC?4.) If HRESP, HREADY & HRDATA are sampled AFTER the data_phase is finished (2 clock cycles after the the transaction has been sent by the manager or sampled by the subordinate, 1 for the control_phase + 1 for the data_phase), How does the manager get to know that there was an error with the transaction it sent 2 CLOCK CYCLES ago? (since there are already at least 1 or more transactions sent by the Manager during that time)5) If the subordinate requires more time to finish an operation, and asks for wait states, how does that happen exactly in the case of pipelining, since again as stated above, the subordinates responses are sampled at least 1.5 or 2 clock cycles later after it was initially sent.
Answering your third question first might go a long way to answering some of the other questions...
3. When the protocol is described as a single edge protocol it means that all events on the bus occur around rising edges of the HCLK clock. Falling edges are not used, so the duty cycle of the clock is not important, only the rising edges.
So all outputs are driven from a rising edge of the clock, and all inputs are sampled on the rising edge of the clock, meaning that signals have a full clock cycle to progress from source to destination (no half clock cycle paths that might limit maximum frequency).
1. HRDATA sampling and driving.
Knowing now that all events are HCLK rising edge related, HRDATA is driven by a subordinate following an HCLK rising edge, and is sampled by the manager on an HCLK rising edge when HREADY is also sampled high (this indicating the end of the data phase transfer).
Figure 3-1 in the protocol shows HRDATA being driven, but it's not a diagram I like as it shows a LONG propagation delay from HRDATA being driven at the start of the data phase (it could wrongly imply HRDATA is actually related to HCLK falling), so figure 3-3 might be a better reference.
So at the start of the transfer data phase the subordinate will start driving HRDATA from that HCLK rising edge if it has the requested data available in time to meet any setup times for the manager sampling HRDATA on the next HCLK rising edge, or it can add one or more wait states by taking HREADY low until such times as it has the requested read data available for driving (figure 3-3 shows HRDATA as unknown for 2 HCLK cycles, and driven valid in the 3rd cycle when HREADY goes high).
2. HREADY and HRESP, like all other signals are driven and sampled using HCLK rising edges.
There can be a significant propagation delay on HRDATA settling as it could be driven directly from memory, or has many bits to settle, but HREADYOUT is a single bit to settle, and the subordinate will know immediately the data phase starts whether or not a wait state will be needed.
Similarly HRESP will be known, or can be a default value of OKAY until such times as the subordinate knows that an ERROR response might be required.
4. HRESP, HREADY and HRDATA are sampled AT the end of the data, not AFTER it has finished.
Have a look at figure 3-17 as that shows what happens when an ERROR occurs.
Yes, a transaction completes 2 cycles (minimum) after the manager first starts the address phase transfer request. So in figure 3-17 the transfer request is T0-T1, and the data phase starts at T1 (because HREADY was sampled high, indicating the end of the previous transfer data phase).In T1-T3 the subordinate is adding two wait states while it works out how to respond to the requested transfer.
At T3 it knows that the SEQ transfer to address 0x24 needs an ERROR response, so it drives HREADY low and HRESP=ERROR at T3.
At T4 the manager sampled HRESP=ERROR and HREADY=0 and knows that this is the first cycle of a 2 cycle ERROR response. The manager at T4 will then change HTRANS to indicate IDLE instead of the SEQ to 0x28 that it was signalling. This ensures that all transfers complete in order because the SEQ to 0x28 has not yet been sampled by any subordinate (because HREADY has not yet been high).
At T4 the subordinate drives the second of the 2 cycle ERROR response, this time with HREADY high.
So at T5 the manager samples HREADY high indicating the data phase transfer has completed (albeit with an ERROR response), and as no new transfer has been started after the failed SEQ to 0x24, the manager is now free to jump to an abort handler routine to hopefully fix the cause of the ERROR.
5. How do wait states affect pipelining
Hopefully as described in the answer to 4., wait states just stall the pipelining. The pipeline only moves on when HREADY is sampled high, so a wait state (or multiple wait states) just stall the bus. No manager transfers are missed, and no subordinate responses are missed. Everyone is waiting to sample HREADY high to indicate when inputs should be sampled and outputs updated for the next transfer.
Does that help ?
Very much so, very thankful for your answer & time, like, really... However there remains one thing I do not quite grasp, Sure HREADY controls the sampling of the subordinate's inputs and outputs sampling.1)Assuming the manager waits for HREADY to be high for it to send another transaction, I am not sure this is what you mean because I've scrolled through other questions where you explicitily explained that HREADY does not control or influence the master's operation in anyway, it just indicates that there's an issue or a wait state, but won't explicitly force the master to NOT send other transactions or otherwise. (correct me if I'm wrong)2) Assuming 1st assumption is right, or wrong, in this case it won't matter much. In pipelined designs, 3 or 2 Clock cycles for HREADY to be asserted/sampled and that is enough time for the master to be sending another 2 or less control signals, and they'd already be inside the subordinate by then, sure the subordinate will not act accordingly(the signals will not progress through the pipelining stages) due to HREADY not being asserted, but what is the manager's understanding of this? does it somehow know that if HREADY is asserted, that the previous control signals sent to the subordinate will not propagate and will, in doing so, in case of a RAM peripheral for example, are not for example written in the RAM?I hope I'm making sense
1) The AHB operates in a pipelined manner, so while one transfer is completing a data phase transfer (controlled by HREADY), the manager is signaling the next transfer address phase. This address phase will be sampled by the next selected subordinate when the currently data phase active subordinate drives HREADY high.
Hopefully none of my other replies have suggested that HREADY does not influence the manager's operation in any way. It is the exact opposite in fact, with HREADY controlling EVERYTHING that happens on the bus.
So the manager is already signaling the next transfer (address phase) while the previous transfer data phase is being performed, and it is the active subordinate returning HREADY high that this current transfer data phase transfer can complete, and the next transfer address phase request should now be sampled by the next selected subordinate. HREADY high allows the manager state machine to progress from this address phase transfer request to the next.
2) I don't think I fully understand what you are describing here. The current data phase transfer could take 2 or 3 HCLK cycles to complete (that all depends on how quickly the selected subordinate can perform the requested data transfer), but during these 2 or 3 cycles the manager will be indicating the next transfer address phase. The manager is stalled while HREADY is low during these 2 or 3 cycles needed to complete that data phase operation.
So you only ever have one transfer in the data phase of operation (when the requested data transfer is being performed, with HREADY from this subordinate indicating when this data phase transfer will end), and the next transfer in the address phase of operation (with this address phase remaining pending until HREADY is sampled high indicating the current data phase is completing).