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

251 lines
9.0 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"] :>
axi_dmac: Make debug register optional The debug registers are useful during development but are rarely used in a production design. Add a option that allows to disable them, this reduces the resource utilization of the DMAC. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2017-03-30 14:00:51 +00:00
<: set disable_debug_registers [getBooleanValue "DISABLE_DEBUG_REGISTERS"] :>
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 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: Update IP with the new util_axis_fifo Update instantiation, false path definitions and make file.
2020-11-18 16:15:45 +00:00
-filter {NAME =~ *i_src_req_fifo/zerodeep.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: Update IP with the new util_axis_fifo Update instantiation, false path definitions and make file.
2020-11-18 16:15:45 +00:00
-filter {NAME =~ *i_src_req_fifo/zerodeep.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 \
axi_dmac: Revert EOT memory to FIFO structure This reverts commit 4b1d9fc86b76 "axi_dmac: Modified in order to avoid vivado crash". Vivado no longer crashes and this structure is much more efficient when it comes to resource usage and timing. The intention here is to create a 1-bit memory that is N entries deep and not a N bit signal. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2018-04-27 16:00:20 +00:00
-from $req_clk \
-through [get_cells -quiet -hier DP \
axi_dmac: drive destination eot from source side
2018-08-03 12:52:55 +00:00
-filter {NAME =~ *i_request_arb/eot_mem_src_reg*}] \
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]
axi_dmac: early abort support Data mover/ src axis changes Request rewind ID if TLAST received during non-last burst Consume (ignore) descriptors until last segment received Block descriptors towards destination until last segment received Request generator changes Rewind the burst ID if rewind request received Consume (ignore) descriptors until last segment received If TLAST happened on last segment replay next transfer (in progress or completed) with the adjusted ID Create completion requests for ignored segments Response generator changes Track requests Complete segments which got ignored
2018-08-25 04:57:20 +00:00
set_max_delay -quiet -datapath_only \
-from $src_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Update IP with the new util_axis_fifo Update instantiation, false path definitions and make file.
2020-11-18 16:15:45 +00:00
-filter {NAME =~ *i_rewind_req_fifo/zerodeep.i_waddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: early abort support Data mover/ src axis changes Request rewind ID if TLAST received during non-last burst Consume (ignore) descriptors until last segment received Block descriptors towards destination until last segment received Request generator changes Rewind the burst ID if rewind request received Consume (ignore) descriptors until last segment received If TLAST happened on last segment replay next transfer (in progress or completed) with the adjusted ID Create completion requests for ignored segments Response generator changes Track requests Complete segments which got ignored
2018-08-25 04:57:20 +00:00
[get_property -min PERIOD $src_clk]
set_max_delay -quiet -datapath_only \
axi_dmac: fix timing constraints When source clock is asynchronous to request clock the rewind request handshake block must be constrained based on request clock domain.
2019-07-26 12:07:51 +00:00
-from $req_clk \
axi_dmac: early abort support Data mover/ src axis changes Request rewind ID if TLAST received during non-last burst Consume (ignore) descriptors until last segment received Block descriptors towards destination until last segment received Request generator changes Rewind the burst ID if rewind request received Consume (ignore) descriptors until last segment received If TLAST happened on last segment replay next transfer (in progress or completed) with the adjusted ID Create completion requests for ignored segments Response generator changes Track requests Complete segments which got ignored
2018-08-25 04:57:20 +00:00
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Update IP with the new util_axis_fifo Update instantiation, false path definitions and make file.
2020-11-18 16:15:45 +00:00
-filter {NAME =~ *i_rewind_req_fifo/zerodeep.i_raddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: fix timing constraints When source clock is asynchronous to request clock the rewind request handshake block must be constrained based on request clock domain.
2019-07-26 12:07:51 +00:00
[get_property -min PERIOD $req_clk]
axi_dmac: early abort support Data mover/ src axis changes Request rewind ID if TLAST received during non-last burst Consume (ignore) descriptors until last segment received Block descriptors towards destination until last segment received Request generator changes Rewind the burst ID if rewind request received Consume (ignore) descriptors until last segment received If TLAST happened on last segment replay next transfer (in progress or completed) with the adjusted ID Create completion requests for ignored segments Response generator changes Track requests Complete segments which got ignored
2018-08-25 04:57:20 +00:00
set_max_delay -quiet -datapath_only \
-from [get_cells -quiet -hier *cdc_sync_fifo_ram_reg* \
-filter {NAME =~ *i_rewind_req_fifo* && IS_SEQUENTIAL}] \
axi_dmac: fix timing constraints When source clock is asynchronous to request clock the rewind request handshake block must be constrained based on request clock domain.
2019-07-26 12:07:51 +00:00
-to $req_clk \
[get_property -min PERIOD $req_clk]
axi_dmac: early abort support Data mover/ src axis changes Request rewind ID if TLAST received during non-last burst Consume (ignore) descriptors until last segment received Block descriptors towards destination until last segment received Request generator changes Rewind the burst ID if rewind request received Consume (ignore) descriptors until last segment received If TLAST happened on last segment replay next transfer (in progress or completed) with the adjusted ID Create completion requests for ignored segments Response generator changes Track requests Complete segments which got ignored
2018-08-25 04:57:20 +00:00
set_false_path -quiet \
-from $req_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
-filter {NAME =~ *sync_rewind/i_sync_out* && IS_SEQUENTIAL}]
set_false_path -quiet \
-from $src_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
-filter {NAME =~ *sync_rewind/i_sync_in* && 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
<: } :>
<: 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 $dest_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Update IP with the new util_axis_fifo Update instantiation, false path definitions and make file.
2020-11-18 16:15:45 +00:00
-filter {NAME =~ *i_dest_response_fifo/zerodeep.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: Update IP with the new util_axis_fifo Update instantiation, false path definitions and make file.
2020-11-18 16:15:45 +00:00
-filter {NAME =~ *i_dest_response_fifo/zerodeep.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]
<: } :>
<: 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: Rework data store-and-forward buffer Currently the DMAC uses a simple FIFO as the store-and-forward buffer. The FIFO handshaking is beat based whereas the remainder of the DMAC is burst based. This means that additional control signals have to be combined with the FIFO handshaking signal to generate the external handshaking signals. Re-work the store-and-forward buffer to utilize a BRAM that is subdivided into N segments. Where N is the maximum number of bursts that can be stored in the buffer and each segment has the size of the maximum burst length. Each segment stores the data associated with one burst and even when the burst is shorter than the maximum burst length the next burst will be stored in the next segment. The new store-and-forward buffer takes care of generating all the handshaking signals. This means handshaking is generated in a central place and does not have to be combined from multiple data-paths simplifying the overall logic. The new store-and-forward buffer also takes care of data width up- and down-sizing in case that the source and sink modules have a different data width. This tighter integration will allow future enhancements like using asymmetric memory. This re-work lays the foundation of future enhancements to the DMA like support for un-aligned transfers and early transfer abort which would have been much more difficult to implement with the previous architecture. In addition it significantly reduces the resource utilization of the store-and-forward buffer and allows for better timing due to reduced combinatorial path lengths. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2018-05-09 16:02:41 +00:00
-filter {NAME =~ *i_store_and_forward/i_dest_sync_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 $dest_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Rework data store-and-forward buffer Currently the DMAC uses a simple FIFO as the store-and-forward buffer. The FIFO handshaking is beat based whereas the remainder of the DMAC is burst based. This means that additional control signals have to be combined with the FIFO handshaking signal to generate the external handshaking signals. Re-work the store-and-forward buffer to utilize a BRAM that is subdivided into N segments. Where N is the maximum number of bursts that can be stored in the buffer and each segment has the size of the maximum burst length. Each segment stores the data associated with one burst and even when the burst is shorter than the maximum burst length the next burst will be stored in the next segment. The new store-and-forward buffer takes care of generating all the handshaking signals. This means handshaking is generated in a central place and does not have to be combined from multiple data-paths simplifying the overall logic. The new store-and-forward buffer also takes care of data width up- and down-sizing in case that the source and sink modules have a different data width. This tighter integration will allow future enhancements like using asymmetric memory. This re-work lays the foundation of future enhancements to the DMA like support for un-aligned transfers and early transfer abort which would have been much more difficult to implement with the previous architecture. In addition it significantly reduces the resource utilization of the store-and-forward buffer and allows for better timing due to reduced combinatorial path lengths. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2018-05-09 16:02:41 +00:00
-filter {NAME =~ *i_store_and_forward/i_src_sync_id* && IS_SEQUENTIAL}] \
[get_property -min PERIOD $dest_clk]
set_max_delay -quiet -datapath_only \
-from $src_clk \
-through [get_cells -quiet -hier \
-filter {IS_SEQUENTIAL && NAME =~ *i_store_and_forward/burst_len_mem_reg*}] \
-to $dest_clk \
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: wire destination descriptor through source Drive the descriptor from the source side to destination so we can abort consecutive transfers in case TLAST asserts. For AXIS count the length of the burst and pass that value to the destination instead the programmed one. This is useful when the streams aborts early by asserting the TLAST. We want to notify the destination with the right number of beats received. For FIFO source interface reuse the same logic due the small footprint even if the stream does not got interrupted in that case. For MM source interface wire the burst length from the request side to destination.
2018-07-27 14:06:53 +00:00
set_max_delay -quiet -datapath_only \
-from $src_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Update IP with the new util_axis_fifo Update instantiation, false path definitions and make file.
2020-11-18 16:15:45 +00:00
-filter {NAME =~ *i_dest_req_fifo/zerodeep.i_waddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: wire destination descriptor through source Drive the descriptor from the source side to destination so we can abort consecutive transfers in case TLAST asserts. For AXIS count the length of the burst and pass that value to the destination instead the programmed one. This is useful when the streams aborts early by asserting the TLAST. We want to notify the destination with the right number of beats received. For FIFO source interface reuse the same logic due the small footprint even if the stream does not got interrupted in that case. For MM source interface wire the burst length from the request side to destination.
2018-07-27 14:06:53 +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: Update IP with the new util_axis_fifo Update instantiation, false path definitions and make file.
2020-11-18 16:15:45 +00:00
-filter {NAME =~ *i_dest_req_fifo/zerodeep.i_raddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: wire destination descriptor through source Drive the descriptor from the source side to destination so we can abort consecutive transfers in case TLAST asserts. For AXIS count the length of the burst and pass that value to the destination instead the programmed one. This is useful when the streams aborts early by asserting the TLAST. We want to notify the destination with the right number of beats received. For FIFO source interface reuse the same logic due the small footprint even if the stream does not got interrupted in that case. For MM source interface wire the burst length from the request side to destination.
2018-07-27 14:06:53 +00:00
[get_property -min PERIOD $dest_clk]
set_max_delay -quiet -datapath_only \
-from [get_cells -quiet -hier *cdc_sync_fifo_ram_reg* \
-filter {NAME =~ *i_dest_req_fifo* && IS_SEQUENTIAL}] \
-to $dest_clk \
[get_property -min PERIOD $dest_clk]
set_max_delay -quiet -datapath_only \
-from $src_clk \
-to [get_cells -quiet -hier *cdc_sync_stage1_reg* \
axi_dmac: Update IP with the new util_axis_fifo Update instantiation, false path definitions and make file.
2020-11-18 16:15:45 +00:00
-filter {NAME =~ *i_src_dest_bl_fifo/zerodeep.i_waddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: wire destination descriptor through source Drive the descriptor from the source side to destination so we can abort consecutive transfers in case TLAST asserts. For AXIS count the length of the burst and pass that value to the destination instead the programmed one. This is useful when the streams aborts early by asserting the TLAST. We want to notify the destination with the right number of beats received. For FIFO source interface reuse the same logic due the small footprint even if the stream does not got interrupted in that case. For MM source interface wire the burst length from the request side to destination.
2018-07-27 14:06:53 +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: Update IP with the new util_axis_fifo Update instantiation, false path definitions and make file.
2020-11-18 16:15:45 +00:00
-filter {NAME =~ *i_src_dest_bl_fifo/zerodeep.i_raddr_sync* && IS_SEQUENTIAL}] \
axi_dmac: wire destination descriptor through source Drive the descriptor from the source side to destination so we can abort consecutive transfers in case TLAST asserts. For AXIS count the length of the burst and pass that value to the destination instead the programmed one. This is useful when the streams aborts early by asserting the TLAST. We want to notify the destination with the right number of beats received. For FIFO source interface reuse the same logic due the small footprint even if the stream does not got interrupted in that case. For MM source interface wire the burst length from the request side to destination.
2018-07-27 14:06:53 +00:00
[get_property -min PERIOD $dest_clk]
set_max_delay -quiet -datapath_only \
-from [get_cells -quiet -hier *cdc_sync_fifo_ram_reg* \
-filter {NAME =~ *i_src_dest_bl_fifo* && IS_SEQUENTIAL}] \
-to $dest_clk \
[get_property -min PERIOD $dest_clk]
axi_dmac: drive destination eot from source side
2018-08-03 12:52:55 +00:00
set_max_delay -quiet -datapath_only \
-from $src_clk \
-through [get_cells -quiet -hier DP \
-filter {NAME =~ *i_request_arb/eot_mem_dest_reg*}] \
-to $dest_clk \
[get_property -min PERIOD $dest_clk]
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 \
axi_dmac: Rework transfer shutdown The DMAC allows a transfer to be aborted. When a transfer is aborted the DMAC shuts down as fast as possible while still completing any pending transactions as required by the protocol specifications of the port. E.g. for AXI-MM this means to complete all outstanding bursts. Once the DMAC has entered an idle state a special synchronization signal is send to all modules. This synchronization signal instructs them to flush the pipeline and remove any stale data and metadata associated with the aborted transfer. Once all data has been flushed the DMAC enters the shutdown state and is ready for the next transfer. In addition each module has a reset that resets the modules state and is used at system startup to bring them into a consistent state. Re-work the shutdown process to instead of flushing the pipeline re-use the startup reset signal also for shutdown. To manage the reset signal generation introduce the reset manager module. It contains a state machine that will assert the reset signals in the correct order and for the appropriate duration in case of a transfer shutdown. The reset signal is asserted in all domains until it has been asserted for at least 4 clock cycles in the slowest domain. This ensures that the reset signal is not de-asserted in the faster domains before the slower domains have had a chance to process the reset signal. In addition the reset signal is de-asserted in the opposite direction of the data flow. This ensures that the data sink is ready to receive data before the data source can start sending data. This simplifies the internal handshaking. This approach has multiple advantages. * Issuing a reset and removing all state takes less time than explicitly flushing one sample per clock cycle at a time. * It simplifies the logic in the faster clock domains at the expense of more complicated logic in the slower control clock domain. This allows for higher fMax on the data paths. * Less signals to synchronize from the control domain to the data domains The implementation of the pause mode has also slightly changed. Pause is now a simple disable of the data domains. When the transfer is resumed after a pause the data domains are re-enabled and continue at their previous state. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2017-09-21 14:02:44 +00:00
-from [get_cells -quiet -hier *do_reset_reg* \
-filter {NAME =~ *i_reset_manager* && IS_SEQUENTIAL}] \
-to [get_pins -quiet -hier *reset_async_reg*/PRE]
set_false_path -quiet \
-from [get_cells -quiet -hier *reset_async_reg[0] \
-filter {NAME =~ *i_reset_manager* && IS_SEQUENTIAL}] \
-to [get_cells -quiet -hier *reset_async_reg[3]* \
-filter {NAME =~ *i_reset_manager* && IS_SEQUENTIAL}]
set_false_path -quiet \
-from [get_cells -quiet -hier *reset_async_reg[0] \
-filter {NAME =~ *i_reset_manager* && IS_SEQUENTIAL}] \
-to [get_pins -quiet -hier *reset_sync_in_reg*/PRE \
-filter {NAME =~ *i_reset_manager*}]
set_false_path -quiet \
-from [get_cells -quiet -hier *reset_sync_reg[0] \
-filter {NAME =~ *i_reset_manager* && IS_SEQUENTIAL}] \
-to [get_pins -quiet -hier *reset_sync_in_reg*/PRE \
-filter {NAME =~ *i_reset_manager*}]
set_property -dict { \
SHREG_EXTRACT NO \
ASYNC_REG TRUE \
axi_dmac: Remove unused constraint The constraint referred to registers which got renamed, causing critical warnings.
2018-07-06 11:37:58 +00:00
} [get_cells -quiet -hier *reset_async_reg*]
axi_dmac: Rework transfer shutdown The DMAC allows a transfer to be aborted. When a transfer is aborted the DMAC shuts down as fast as possible while still completing any pending transactions as required by the protocol specifications of the port. E.g. for AXI-MM this means to complete all outstanding bursts. Once the DMAC has entered an idle state a special synchronization signal is send to all modules. This synchronization signal instructs them to flush the pipeline and remove any stale data and metadata associated with the aborted transfer. Once all data has been flushed the DMAC enters the shutdown state and is ready for the next transfer. In addition each module has a reset that resets the modules state and is used at system startup to bring them into a consistent state. Re-work the shutdown process to instead of flushing the pipeline re-use the startup reset signal also for shutdown. To manage the reset signal generation introduce the reset manager module. It contains a state machine that will assert the reset signals in the correct order and for the appropriate duration in case of a transfer shutdown. The reset signal is asserted in all domains until it has been asserted for at least 4 clock cycles in the slowest domain. This ensures that the reset signal is not de-asserted in the faster domains before the slower domains have had a chance to process the reset signal. In addition the reset signal is de-asserted in the opposite direction of the data flow. This ensures that the data sink is ready to receive data before the data source can start sending data. This simplifies the internal handshaking. This approach has multiple advantages. * Issuing a reset and removing all state takes less time than explicitly flushing one sample per clock cycle at a time. * It simplifies the logic in the faster clock domains at the expense of more complicated logic in the slower control clock domain. This allows for higher fMax on the data paths. * Less signals to synchronize from the control domain to the data domains The implementation of the pause mode has also slightly changed. Pause is now a simple disable of the data domains. When the transfer is resumed after a pause the data domains are re-enabled and continue at their previous state. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2017-09-21 14:02:44 +00:00
set_property -dict { \
SHREG_EXTRACT NO \
ASYNC_REG TRUE \
} [get_cells -quiet -hier *reset_sync_reg*]
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
# Ignore timing for debug signals to register map
axi_dmac: Make debug register optional The debug registers are useful during development but are rarely used in a production design. Add a option that allows to disable them, this reduces the resource utilization of the DMAC. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2017-03-30 14:00:51 +00:00
<: if {!$disable_debug_registers} { :>
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_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: Route destination request ID through the burst memory Currently the destination side request ID is synchronized response ID from the source side. This signal is effectively the same as the synchronized src ID inside the burst memory. The only difference is that they might not increment in the exact same clock cycle. Exporting the request ID from the burst memory means we can remove the extra synchronizer block. This has the added bonus that the request ID will increment in the same clock cycle as when the data becomes available from the memory. This means we can assume that when there is a outstanding burst request indicated via the ID that data is available from the memory and vice versa when data is available from the memory that there is a outstanding burst request. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2018-05-10 09:13:22 +00:00
-filter {name =~ *i_dest_sync_id* && IS_SEQUENTIAL}] \
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
-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}]
axi_dmac: Rework transfer shutdown The DMAC allows a transfer to be aborted. When a transfer is aborted the DMAC shuts down as fast as possible while still completing any pending transactions as required by the protocol specifications of the port. E.g. for AXI-MM this means to complete all outstanding bursts. Once the DMAC has entered an idle state a special synchronization signal is send to all modules. This synchronization signal instructs them to flush the pipeline and remove any stale data and metadata associated with the aborted transfer. Once all data has been flushed the DMAC enters the shutdown state and is ready for the next transfer. In addition each module has a reset that resets the modules state and is used at system startup to bring them into a consistent state. Re-work the shutdown process to instead of flushing the pipeline re-use the startup reset signal also for shutdown. To manage the reset signal generation introduce the reset manager module. It contains a state machine that will assert the reset signals in the correct order and for the appropriate duration in case of a transfer shutdown. The reset signal is asserted in all domains until it has been asserted for at least 4 clock cycles in the slowest domain. This ensures that the reset signal is not de-asserted in the faster domains before the slower domains have had a chance to process the reset signal. In addition the reset signal is de-asserted in the opposite direction of the data flow. This ensures that the data sink is ready to receive data before the data source can start sending data. This simplifies the internal handshaking. This approach has multiple advantages. * Issuing a reset and removing all state takes less time than explicitly flushing one sample per clock cycle at a time. * It simplifies the logic in the faster clock domains at the expense of more complicated logic in the slower control clock domain. This allows for higher fMax on the data paths. * Less signals to synchronize from the control domain to the data domains The implementation of the pause mode has also slightly changed. Pause is now a simple disable of the data domains. When the transfer is resumed after a pause the data domains are re-enabled and continue at their previous state. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2017-09-21 14:02:44 +00:00
set_false_path -quiet \
-from [get_cells -quiet -hier *reset_sync_reg* -filter {name =~ *i_reset_manager* && IS_SEQUENTIAL}] \
-to [get_cells -quiet -hier *up_rdata_reg* -filter {IS_SEQUENTIAL}]
axi_dmac: Make debug register optional The debug registers are useful during development but are rarely used in a production design. Add a option that allows to disable them, this reduces the resource utilization of the DMAC. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
2017-03-30 14:00:51 +00:00
<: } :>