Ignoring #pragma to allocate uram on HLS action and using bram instead w/ AD9V3

[diamantopoulos]

Dear all,

I'm facing the following issue with an HLS action on AD9V3 card:
I'm trying to force the use of uram (ultraram) instead of BRAM on one of my designs. For this, I set the relative #pragma :
#pragma HLS RESOURCE variable=buffer core=XPM_MEMORY uram

When I perform HLS synthesis I get the expected allocation:

But when I perform make image to get the final bitstream, I realize that synthesis (RTL) never allocated urams and used brams instead:

I've added a branch that replicates this issue on hls_decimal_mult example: i.e. in HLS synthesis you get urams reserved for the I/O buffers but when you synthesize the design, only brams are used.

I couldn't find any error/warning in SNAP logs that prohibits the uram allocation. Can this be related to a synthesis strategy or missing design files (IP, constraints etc.)?

thanks --d

[bmesnet]

Logging a summary of the discussion for information:
It seems that the generated vhdl files (in actions/hls_decimal_mult/hw/hls_syn_vhdl) - of the memories (e.g. process_action_bubkb.vhd) differ in that way:

Left: with #pragma HLS RESOURCE variable=buffer core=XPM_MEMORY uram - Right without #pragma

This is found using Vivado HLS 2018.2

When using Vivado HLS 2018.3, it generates the following vhdl:

Testing that to see if this solves the issue.
FYI Vivado HLS release can be used with a different Vivado release

[diamantopoulos]

It seems to be an issue with Vivado HLS <= 2018.2.
Vivado HLS 2018.3 genetares VHDL code for the memories with the keyword "uram" when the following pragma is used:
#pragma HLS RESOURCE variable=buffer core=XPM_MEMORY uram

The use of urams has been verified to be present down to post P&R netlist

Thanks all for helping!