Add support for querying the clock domains of the clock pins for the
axi_dmac controller. This allows the core to automatically figure out
whether its different parts run in different clock domains or not and setup
the configuration parameters accordingly.
Being able to auto-detect those configuration parameters makes the core
easier to use and also avoids accidental misconfiguration.
It is still possible to automatically overwrite the configuration
parameters by hand if necessary.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
bd files can be used to automate certain tasks in IP integrator when the
core is instantiated. Add a helper command for adding such files to a core.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For the source controller use the pause signal that has been properly
transferred to the source clock domain rather than the pause signal from
the request clock domain.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When having multiple DMA cores sharing the same constraint file Vivado
seems to apply the constraints from the first core to all the other cores
when re-running synthesis and implementation from within the Vivado GUI.
This causes wrong timing constraints if the DMA cores have different
configurations. To avoid this issue use a TTCL template that generates a
custom constraint file for each DMA core instance.
This also allows us to drop the asynchronous clock detection hack from the
constraint file and move it to the template and only generate the CDC
constraints if the clock domains are asynchronous.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The synchronization interface is a single bidirectional line. Output for Master, input for Slave.
The sync_period value is relative to frame length and the digital interface clock. The actual synchronization
period will be: sync_period * frame_length * fb_clock_cycle
The memory mapped AXI interfaces for the AXI-DMAC are uni-directional.
Which means they are either write-only or read-only. Unfortunately the
Altera tools can't handle this, so we had to add dummy signals for the
other direction.
The Xilinx tools on the other hand handle uni-directional AXI interfaces
and in fact IPI can do a better job and use less resources when creating
the AXI interconnects when it knows that the interface is uni-directional.
So always disable the dummy ports for the IPI package.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For some reason, if a core has an AXI and an AXI Stream interface too, the tool sets the AXI interface's ASSOCIATED_RESET parameter to the AXI Stream interface's reset.
This cause an unconnected AXI reset port in the block design. This 'set_property' command intended to overwrite this automated setup.
Lars-Peter Clausen
Adrian Costina
Istvan Csomortani
Rejeesh Kutty