From 5aa11feb487cb4fc01f3b0cbe1b703cce543a0c1 Mon Sep 17 00:00:00 2001 From: Lars-Peter Clausen Date: Thu, 17 Sep 2015 11:06:36 +0200 Subject: [PATCH] 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 --- library/axi_dmac/axi_dmac_constr.ttcl | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/library/axi_dmac/axi_dmac_constr.ttcl b/library/axi_dmac/axi_dmac_constr.ttcl index 388c3c891..43befdab1 100644 --- a/library/axi_dmac/axi_dmac_constr.ttcl +++ b/library/axi_dmac/axi_dmac_constr.ttcl @@ -135,11 +135,12 @@ set_max_delay -quiet -datapath_only \ -filter {NAME =~ *i_fifo/i_address_gray/i_raddr_sync* && PRIMITIVE_SUBGROUP == flop}] \ [get_property -min PERIOD $dest_clk] -# Not sure why, but it seems the built-in constraints for the RAM36B are wrong -set_max_delay -quiet -datapath_only \ - -from $dest_clk \ - -to [get_pins -hier *ram_reg*/REGCEB -filter {NAME =~ *i_fifo*}] \ - [get_property -min PERIOD $dest_clk] +# 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*}] <: } :> # Reset signals