zcy
/
pluto_hdl_adi
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
pluto_hdl_adi/library/axi_dmac/axi_dmac_constr.ttcl

168 lines
6.2 KiB
Plaintext
Raw Normal View History

axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
<: set ComponentName [getComponentNameString] :>
<: setOutputDirectory "./" :>
<: setFileName [ttcl_add $ComponentName "_constr"] :>
<: setFileExtension ".xdc" :>
<: setFileProcessingOrder late :>
<: set async_dest_req [getBooleanValue "ASYNC_CLK_DEST_REQ"] :>
<: set async_req_src [getBooleanValue "ASYNC_CLK_REQ_SRC"] :>
<: set async_src_dest [getBooleanValue "ASYNC_CLK_SRC_DEST"] :>
set req_clk [get_clocks -of_objects [get_ports s_axi_aclk]]
set src_clk [get_clocks -of_objects [get_ports -quiet {fifo_wr_clk s_axis_aclk m_src_axi_aclk}]]
set dest_clk [get_clocks -of_objects [get_ports -quiet {fifo_rd_clk m_axis_aclk m_dest_axi_aclk}]]
axi_dmac: Don't add CDC constraints when all clocks are synchronous When all clocks are synchronous there are no synchronizers and the constraint for the CDC registers can't find any cells which generates a warning. To avoid this don't add CDC constraints when all the clocks are synchronous. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2015-11-06 14:17:55 +00:00
<: if {$async_req_src || $async_src_dest || $async_dest_req} { :>
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
set_property ASYNC_REG TRUE \
[get_cells -quiet -hier *cdc_sync_stage1_reg*] \
[get_cells -quiet -hier *cdc_sync_stage2_reg*]
axi_dmac: Don't add CDC constraints when all clocks are synchronous When all clocks are synchronous there are no synchronizers and the constraint for the CDC registers can't find any cells which generates a warning. To avoid this don't add CDC constraints when all the clocks are synchronous. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2015-11-06 14:17:55 +00:00
<: } :>
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
<: if {$async_req_src} { :>
set_max_delay -quiet -datapath_only \
-from $req_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_sync_src_request_id* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $req_clk]
set_false_path -quiet \
-from $src_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_sync_status_src* && IS_SEQUENTIAL}]
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
set_false_path -quiet \
-from $req_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_sync_control_src* && IS_SEQUENTIAL}]
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
set_max_delay -quiet -datapath_only \
-from $req_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_src_req_fifo/i_waddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $req_clk]
set_max_delay -quiet -datapath_only \
-from $src_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_src_req_fifo/i_raddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $src_clk]
set_max_delay -quiet -datapath_only \
-from [get_cells -quiet -hier *cdc_sync_fifo_ram_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_src_req_fifo* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
-to $src_clk \
[get_property -min PERIOD $src_clk]
set_max_delay -quiet -datapath_only \
-from [get_cells -quiet -hier *eot_mem_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_request_arb* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
-to $src_clk \
[get_property -min PERIOD $src_clk]
<: } :>
<: if {$async_dest_req} { :>
set_max_delay -quiet -datapath_only \
-from $dest_clk \
-to [get_cells -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_sync_req_response_id* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $dest_clk]
set_false_path -quiet \
-from $dest_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_sync_status_dest* && IS_SEQUENTIAL}]
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
set_false_path -quiet \
-from $req_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_sync_control_dest* && IS_SEQUENTIAL}]
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
set_max_delay -quiet -datapath_only \
-from $req_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_dest_req_fifo/i_waddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $req_clk]
set_max_delay -quiet -datapath_only \
-from $dest_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_dest_req_fifo/i_raddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $dest_clk]
set_max_delay -quiet -datapath_only \
-from [get_cells -quiet -hier *cdc_sync_fifo_ram_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_dest_req_fifo* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
-to $dest_clk \
[get_property -min PERIOD $dest_clk]
set_max_delay -quiet -datapath_only \
-from $dest_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_dest_response_fifo/i_waddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $dest_clk]
set_max_delay -quiet -datapath_only \
-from $req_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_dest_response_fifo/i_raddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $req_clk]
set_max_delay -quiet -datapath_only \
-from [get_cells -quiet -hier *cdc_sync_fifo_ram_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_dest_response_fifo* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
-to $req_clk \
[get_property -min PERIOD $req_clk]
set_max_delay -quiet -datapath_only \
-from [get_cells -quiet -hier *eot_mem_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_request_arb* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
-to $dest_clk \
[get_property -min PERIOD $dest_clk]
<: } :>
<: if {$async_src_dest} { :>
set_max_delay -quiet -datapath_only \
-from $src_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_sync_dest_request_id* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $src_clk]
set_max_delay -quiet -datapath_only \
-from $src_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_fifo/i_address_gray/i_waddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $src_clk]
set_max_delay -quiet -datapath_only \
-from $dest_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {NAME =~ *i_fifo/i_address_gray/i_raddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
[get_property -min PERIOD $dest_clk]
axi_dmac: Change BRAM REGCEB constraint to set_false_path According to the documentation when using a BRAM block in SDP mode the REGCEB pin is not used and should be connected to GND. The tools though when inferring a BRAM connect REGCEB to the same signal REGCEA. This causes issues with timing verification since the REGCEB pin is associated with the write clock whereas the REGCEA pin is associated with the read clock. Until this is fixed in the tools mark all paths to the REGCEB pin as false paths. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2015-09-17 09:06:36 +00:00
# In SDP mode REGCEB should not be connected. When inferring the BRAM the tools
# do it anyway. The signal is not used by the BRAM though. But since the clock
# associated with REGCEB is the write clock and not the read clock we get a
# timing problem. Mark the path as a false path so it is not timed.
set_false_path -quiet \
-to [get_pins -hier *ram_reg*/REGCEB -filter {NAME =~ *i_fifo*}]
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
<: } :>
# Reset signals
set_false_path -quiet \
-from $req_clk \
-to [get_pins -quiet -hier *reset_shift_reg*/PRE]
# Ignore timing for debug signals to register map
set_false_path -quiet \
-from [get_cells -quiet -hier *cdc_sync_stage2_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {name =~ *i_sync_src_request_id* && IS_SEQUENTIAL}] \
-to [get_cells -quiet -hier *up_rdata_reg* -filter {IS_SEQUENTIAL}]
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
set_false_path -quiet \
-from [get_cells -quiet -hier *cdc_sync_stage2_reg* \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-filter {name =~ *i_sync_dest_request_id* && IS_SEQUENTIAL}] \
-to [get_cells -quiet -hier *up_rdata_reg* -filter {IS_SEQUENTIAL}]
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
set_false_path -quiet \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-from [get_cells -quiet -hier *id_reg* -filter {name =~ *i_request_arb* && IS_SEQUENTIAL}] \
-to [get_cells -quiet -hier *up_rdata_reg* -filter {IS_SEQUENTIAL}]
axi_dmac: Generate per core instance constraint file 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>
2015-09-15 16:58:40 +00:00
set_false_path -quiet \
axi_dmac: Fix constraints for ultrascale Replace "PRIMITIVE_SUBGROUP == flop" with "IS_SEQUENTIAL" as the former is series7 specific while the later works on all platforms. This fixes the axi_dmac timing constraints for ultrascale based platforms. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2016-10-19 11:44:51 +00:00
-from [get_cells -quiet -hier *address_reg* -filter {name =~ *i_addr_gen* && IS_SEQUENTIAL}] \
-to [get_cells -quiet -hier *up_rdata_reg* -filter {IS_SEQUENTIAL}]