You probably want to use block RAMs (or UltraRAM if available in the device) for memBuffer.
The tools can only place memBuffer in block/Ultra RAMs if you follow the design rules.
Look at "RAM HDL Coding Guidelines" in UG687.
You can also directly instantiate a block/Ultra RAM based memory.
You probably want to use block RAMs (or UltraRAM if available in the device) for memBuffer.
The tools can only place memBuffer in block/Ultra RAMs if you follow the design rules.
Look at "RAM HDL Coding Guidelines" in UG687.
You can also directly instantiate a block/Ultra RAM based memory.
You probably want to use block RAMs (or UltraRAM if available in the device) for memBuffer.
The tools can only place memBuffer in block/Ultra RAMs if you follow the design rules.
Look at "RAM HDL Coding Guidelines" in UG687.
You can also directly instantiate a block/Ultra RAM based memory.
I’m kind of surprised the tool didn’t figure out how to implement the inferred RAM and just tried to stick it all in LUTs. Maybe there’s some configuration bit in the tool about how to implement RAM?
I’m kind of surprised the tool didn’t figure out how to implement the inferred RAM and just tried to stick it all in LUTs. Maybe there’s some configuration bit in the tool about how to implement RAM?
The tool is processing any synthesizable HDL, to guarantee memory implementation in block RAM, you can either write structural code with low level primitives or refer to memory inference templates, otherwise you easily define logic that's incompatible with block RAM capabilities.
The tool is processing any synthesizable HDL, to guarantee memory implementation in block RAM, you can either write structural code with low level primitives or refer to memory inference templates, otherwise you easily define logic that's incompatible with block RAM capabilities.
The block RAM is synchronous. For reading, it clocks in the address in one clock cycle and clocks out the data in the next.
If you assign the address in one clock cycle, the RAM output can be assigned to other signals 2 clock cycles later.
You get the data from an asynchronous distributed RAM one clock cycle earlier.
It is very easy to write code that can't be implemented in block RAMs. The write timing is easy, the read timing is tricky.
It is easier to see/avoid the limitations of the wanted block RAM if it is implemented as a separate clocked process.
For BRAM inferences, you cannot reset the whole memory (or ever parts of them) in one cycle. The BRAM does not support it, thus the tool is inferring LUT instead.
If you need to reset the RAM, you probably need a long reset time (28810 cycles), where each cycle reset one individual BRAM address.
The most common way to proceed is not to reset the RAM and considere the RAM "dirty" after a reset. If you need the RAM cleared for simulation purposes, there are ways to clear the RAM in simulation and even after a FPGA power up, but not after a logic reset in one cycle as you want.