Hello,
The way APB transfer is defined, on cycle:
1. sets SEL=1, sets control signals (address, data, write...etc)
2. sets ENABLE=1, keep control signals static
3. assuming device was ready to accept the data ready=1, sets SEL=0, ENABLE=0
4. sets SEL=1, sets new control signals (address, data, write...etc)
5. Jump to cycle#2 and continue from there
The way the standard sequences the events, it will take 3 cycles for a single transaction.
What benefit does it give to add an extra cycle between SEL and ENABLE signals? Why could not they get asserted on the same cycle and that would make a single transfer within one cycle only (assuming there is no back-pressure). If the subordinate cannot process the data within a cycle it has a way to extent the cycle by keeping the ready at low.
What benefits does it give to push SEL=0 in cycle #3? Why could not I keep it active for back to back transfers?
Thanks in advance,
Khach
Thanks again. That mostly makes sense. Why does the interface require the address to be constant for 2 cycles too? Why cant we capture it during setup (as the spec says) and then do not care about it in access state. This is how the synchronous SRAM would operate, is not it?
You can capture it in the setup phase, that's how I'd expect you to use it so you know what data transfer is required in the access phase.
As for why the address and other controls are held constant during the access phase, as this isn't a pipelined bus (back to the simplicity argument) there isn't any functional reason NOT to keep the address and control signals constant for the duration of the access, and there might be a peripheral design that prefers the signals to still be valid during the data transfer, so why change them ?