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).
Sorry for the late reply, been really sick.1) understood but something to note, will explain in 2)2) To design a pipelined hardware there'd need to be more than that number of clock cycles, let me explain what I mean: A) Sending on the positive edge of T1 from Manager to Subordinate B) Subordinate accepts the transaction and starts the Control Phase on T2 which lasts until T3 C) On T3, Data phase starts, which spans from T3 to T4 D) Sampling of said output @T4 if done sequentially would require it to be sampled on T5 (which I persume is the case since the AHB is a single clock edge protocol, no?*Therefore the scenario you proposed @1) is not viable? since the sampling is done after around 4 clock edges after the Control Phase signals are sent from the manager? which in case would make the SUBORDINATE's response obsolete in nature, since the next transaction that would be sent to the SUBRODINATE after the response would be at T6, while the one sent after the control signal @T1 would be at T2, therefore making the reply in essence, obsolete.currently I'm doing this: A) Sending on the positive edge of T1 from Manager to Subordinate B) Subordinate accepts the transaction and starts the Control Phase on T1 which lasts until T2 C) On T2, Data phase starts, which spans from T2 to T3 D) Sampling of said output @T3 if done sequentially would require it to be sampled on T4 (which I persume is the case since the AHB is a single clock edge protocol, no? but I'm facing an issue with the wrap counter, since it needs more than 1 cycle to be prepared for the wrap transaction (value differs from 1 to 3 to 7 and decrements depending on HBURST being (2, 4, 6) but this is like getting into too much detail? and I don't think I should be doing that since1) I want to solve this by my own.2) I should not bother you with this.I know something is missing from my thought process (probably the inner workings of the subordinate not having to be sequential in anyway, but that also doesn't make sense since burst and wrap transactions require counters, which in turn necessitate a sequential behavior for synthizability, and I totally understand that this is a DESIGN IP issue or an DESIGN IP architect's issue to handle or manage? but I'm currently a trainee and am just trying to implement this project on my own, so I cant get that type of insight.)Please correct me if I'm wrong. Sorry for spamming this much. and Thanks alot for your time and insights. really grateful.
Let's use one of the diagrams from the AHB specification as an example when looking at your ABCD steps, so from ARM IHI 0033C have a look at figure 3-5 as it has Tx reference labels on each HCLK rising edge.
So if we are looking at transfer A in figure 3-5, T0 is probably what you referred to as A, the start of the transfer address phase, manager sending this request to the subordinate.
T1 is when the subordinate samples the address phase request, so the subordinate now knows what transfer is being requested by the manager, so point B in your list, and the transfer data phase starts, which is C in your list.
And at T2 this is the end of the data phase of the transfer, the subordinate samples the data being written, or the manager samples the read data the subordinate is returning, and would be D in your list.
I think what you are describing as the "control phase" is what the AHB protocol refers to as the transfer "address phase", which is when the manager is passing the address and control information to the selected subordinate. There is no "control phase" in addition to the "address phase".
If the subordinate needs additional time to perform the requested data transfer it can add wait states using HREADY, and these extend the data phase operation. This is what you see in figure 3-5 for transfer B, where the data phase extends from T2 to T4 because HREADY was sampled low at T3.
Please have a read at the AHB protocol as this shows how transfers are performed, and how the address and data phases of the transfers are pipelined to maximise bandwidth. If you then have questions, please try and refer to diagrams in the protocol document so we have a common reference for discussions.
Just re-reading your question, if your concern is the manager or subordinate doing address calculations for WRAP type bursts, this should just be a simple incrementation of the start address, adding an AxSIZE increment for each step, but only incrementing the LSBs of the calculated address, so that when you reach the "wrap boundary" the LSB incrementer furst wraps back to 0. So hopefully not massive calculations that need more than one clock cycle.