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 ?