# Forum: FPGA, VHDL & Verilog Xilinx BRAM behaviour query.

Rate this post
 0 ▲ useful ▼ not useful
Hi all

I am using BRAM in standalone mode extensively in my Zynq project, and
it seems to work in all the various conditions in which I have assumed
it to do so. I often use it as a mapping function, using precalculated
data loaded from the ARM (my clients are still at the R&D stage and need
almost complete flexibility in the design).

It can handle interleaving, convolution (encoding only), modulation and
most other functions within the system in a manner dynamically
configurable from the host processor, while maintaining a throughput
equal to the system clock. I'm sure this is very old news to most of
you, being a method which, to be considered novel, would require a
journey back in time of 150 years or more. It was mooted during the
mechanical age of the 19th century, and I believe a Frenchman adopted it
as a method of making complex fabric patterns widely available even
before then. No doubt someone from Iran or China will be able to inform
me of even greater venerability.

I have, however, made an assumption about the behaviour of BRAM output
data which is undocumented. This is that, if the EN input remains
de-asserted, the state of the memory will be frozen, leaving its output
and its internals in the state in which it was most recently accessed.
In other words, I assume EN to be a clock gate. This is certainly true
in the version of BRAM supplied with Vivado 15.4, (which I am coerced
into using with the ZC706 EVB), and seems entirely logical. But is, as
said, undocumented. The type of structure I am using is arbitrarily
pipelined, an address is output to a BRAM, the output of which addresses
another BRAM, and so on, until a BRAM at the end of the chain supplies
data to the AXI4 stream bus, a requirement being that transmission be
stallable in the event the receiving logic de-assert its tready signal.
Tready is used as part of the logic of the EN signal of the chain of
BRAMs, and my reasoning assumes data to be held at values clocked out in
the most recent cycle in which EN was held high. The logic might well be
flawed, but, as it stands, I depend on the permanence of BRAM output
data when EN is de-asserted.

Should I instead gate the clock externally?

Best regards
Julian

: Edited by User

• $formula (LaTeX syntax)$