Make sure that the address generator behaves correctly when the buswidth is not
64-bit. Also since the source and destination can have different widths add
separate parameters for source and destination address alignment.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
We do not know which 'last' condition to use before hand, but we can pre-compute
the result for both conditions and then use them. This removes the comparison
from the already pretty long combinatorial path.
Also simplify a few expressions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The read data also becomes available only with a delay of one clock cycle,
sending the ack too early will result in bogus register reads.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
During an ID sync the request_id might increment, we should not generate a
response in this case. Since the ID sync only happens when the core is disabled
check that the core is enabled before generating a response.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The pending_burst signal and the expression id != request_id are almost
identical. pending_burst goes high with a delay of one clock cycle, but the
important thing is that it goes low on the same clock cycle as the expression.
By using pending_burst here instead of 'id != request_id' we can reduce the
fanout of the 'id' register and improve the timing of the core.
Vivado doesn't handle the case where we use symbolic constants for the default
value properly, so update this to use plain integers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There were a few place in the core where it assumed a 64-bit wide bus. Make this
configurable using parameters. The patch also adds support for having different
DMA bus widths on the source and destination side.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If the address generator is disabled the very same cycle as it tries to put a
new address on the bus, it will keep sending this address forever and the core
will lock up
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Right now there is always a period of one clock cycle where we can not transfer
any data when switching between two transfers. This patch modifies the data
mover to allow for zero latency. This fixes problems on the FMCOMMS1 platform
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Rejeesh Kutty
Lars-Peter Clausen
Adrian Costina