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.
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.