The setup and hold times of all control signals, including Enable (EN), must always be met during assertion and deassertion for all Xilinx FPGA block RAMs.
Violating the setup/hold of EN can cause the first read or write to fail in the Virtex-5, Virtex-6, Spartan-6, and 7 series and UltraScale/UltraScale+ block RAM.
In general, all setup and hold times of a block RAM must be met in order for the block RAM to function as defined in the User Guide.
Under certain conditions, a setup / hold time violation could occur on any control signal (i.e. address, write enable, reset, etc.) to the block RAM while the port enable is active (i.e. ENA/ENB=1) OR the port enable signal itself could have a setup / hold violation.
The setup/hold violation conditions are met when an asynchronous reset (or any other control signal) is deasserted or the clock is lost (even briefly) during device operation (for example, losing input clock to the DCM/MMCM or BUFR/BUFG coming into the BRAM).
In this case the block RAM contents can be corrupted even if the write enables are low, which might result in the first read/write operation not behaving as expected.
It is suggested to avoid this situation by always properly synchronizing all asynchronous signals including reset and to do proper timing analysis.
If this situation cannot be avoided, it is suggested to assert the EN signal one full clock cycle prior to the first read or write. Tying EN to a constant high and thus always enabling the BRAM is also an option.
The Data Sheet: DC and AC Switching Characteristics for each family documents the RAM timing parameters.
The timing is also documented in the Memory Resource User Guide, including Trcck_en and Trckc_en, defined as:
"Trck_en: Time after the clock that the enable signal must be stable at the EN input of the BRAM."
Block RAM as hard FIFO (Virtex-5, Virtex-6, Spartan-6, 7 series)
When using the Built in FIFO with asynchronous clocks, the first word read out after a reset might be incorrect due to timing issues on the reset signal. This issue is seen when instantiating the primitive or potentially when using the FIFO Generator core in Core Generator.
Note: The issue will only be seen when RDCLK and WRCLK are truly asynchronous to each other, clocks generated from the same Clock Manager would not be affected.
If the RDCLK and WRCLK are asynchronous and the Reset of the FIFO is not synchronized to the RDCLK, the first word read out after a reset could potentially be incorrect, even if the reset signal is meeting timing in the Timing Analysis.
This is due to signals that are internally generated within the built-in FIFO. To avoid this issue, synchronize the Reset to the RDCLK and ensure that the other reset requirements of the family are met.
For example, for Virtex-5:
The FIFO Generator Coregen core will automatically synchronize the Reset to the slowest clock. As a result, using FIFO Generator with a WRCLK slower than RDCLK can result in this issue.
The Reset must be synchronized to the RDCLK before being passed to the core.
In UltraScale/UltraScale+ MPSoC devices, there is a synchronizer for the reset to WRCLK, so this no longer applies.