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>

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
+# In SDP mode REGCEB should not be connected. When inferring the BRAM the tools
-set_max_delay -quiet -datapath_only \
+# do it anyway. The signal is not used by the BRAM though. But since the clock
-	-from $dest_clk \
+# associated with REGCEB is the write clock and not the read clock we get a
-	-to [get_pins -hier *ram_reg*/REGCEB -filter {NAME =~ *i_fifo*}] \
+# timing problem. Mark the path as a false path so it is not timed.
-	[get_property -min PERIOD $dest_clk]
+set_false_path -quiet \
+	-to [get_pins -hier *ram_reg*/REGCEB -filter {NAME =~ *i_fifo*}]
 
 <: } :>
 # Reset signals