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>main
parent
9e68357af5
commit
5aa11feb48
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue