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