what does this notification mean?

[h.m]

hi, anybody there to explain this notification?
----------------------------

Xst:3218 - HDL ADVISOR - The RAM <Mram_roundkey[23]_GND_10_o_wide_mux_108_OUT> will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features. If you have described an asynchronous read, making it synchronous would allow you to take advantage of available block RAM resources, for optimized device usage and improved timings. Please refer to your documentation for coding guidelines.

 

[sharath666]

It means that instead of using the FPGA Block RAM hardmacro, it is going to implement the RAM using LUTs(because of the reasons specified).
Please correct your code so that the BRAM is inferred.

 

[h.m]

i don't know how to correct my codes guy, what kind of codes would cause this problem, i'm not perfosinal in this, tnx for your assistance

 

[sreevenkjan]

post your code here. we can point the error.

 

[ads-ee]

Inferring ram? read this

 

[h.m]

tnx very much guys, ads-ee i read your link, there was a phrase there that i bring it below:
---------------------------

Xilinx supports inferring clock-enables on all BRAM types. Altera only seems to support this on simpler forms of memories. Trying to place clock-enables on a true dual-port memory yields the distinctly unhelpful message “RAM logic is uninferred due to asynchronous read logic”.

------------------------------------
it says that xilinx supports inferring clock-enables on all BRAM types but look this link:
-----------------------------
https://www.xilinx.com/support/documentation/ip_documentation/dp_block_mem.pdf
----------------------------
it says:
-------------------

Both the SelectRAM+ and SelectRAM-II memories are True
Dual-Port™ RAM, offering fast, discrete, and large
blocks of memory in the Spartan-II and Virtex device
families.

----------------------
i'm confused, BRAMs in virtex families are true dual-port RAM? so in this case we can not have a clk-enable on it, but in the first sentences i bring here, it said Xilinx supports inferring clock-enables on all BRAM types, so what the problem is?

 

[ads-ee]

Why are you looking at document that is 10 year old and for a discontinued core? The parts you refer to aren't even in production anymore.

 

[h.m]

so what's the problem? if the new productions has this ability, why i have this notification in summery?
ofcourse it's not warning neither error. what kind of notifications are these, and what are they for? that's a exclamation sign in a cloud,

 

[std_match]

We can't help you without some source code.

 

[vGoodtimes]

It is a message that says "This looks like you wanted a RAM in your design. This RAM is large enough that I could use a BRAM, but you described it wrong in some way that I'll be vague about." Because it isn't clear if you actually wanted a BRAM, it isn't an error or warning. (also, inferred RAMs may not be able to make use of all BRAM features, see documentation for details)

In larger devices, you can create 16kbit register-based RAMs (by accident) that take up a lot more space and routing. This also leads to longer build times. This warning is there to alert you to this possibility.

This is an "info" message. These are usually tips or general messages that might not be important.

 

[h.m]

okay, this is my code
----------------

---

Code dot - [expand]
1
2
3
4
5
6
7
8
process (clk) is
begin
if rst = '1' then
DATAOUT <= (others => '0');
elsif (clk='1' and clk'event) then
DATAOUT <= INV_SHIFT_ROW_FUNCT(state);
end if;
end process;

---

-----------------------
would u tell me how i can use these BRAMs?

 

[TrickyDicky]

Ok, the main problem is the asynchronous reset (you forgot to put reset in the sensitivity list btw)
RAMs cannot be reset at all, so you need to remove the reset from the code.

 

[h.m]

why should it use ram for synthesis???
i have alot of codes for ram such these
--------------------------

---

Code dot - [expand]
1
2
3
4
5
6
7
8
case a is
when x"00" => temp := x"52";
when x"01" => temp := x"09";
when x"02" => temp := x"6a";
when x"03" => temp := x"d5";
.
.
.

---

--------------------------------
these codes i think can be synthesised as ram, but the codes in the last message i think should be synthesize as register, and registers can be reset, isn't it?

- - - Updated - - -

i mean that it can use rams, and put a register after it.
i don't know how funny it is, but i did it if i was in its shoes. D

 

[h.m]

any body there? if u did not understand what i say, please say it to me, to write more obvious. anyway tnx for all your helps

 

[sharath666]

It is better to use RAMs as they are anyway there within the FPGA. They will help you to save on area (area used by register bank) and they will also be faster. The flops after the RAM will be inferred anyway. You don't need to write the above code for that...

 

[vGoodtimes]

@h.m, see the xst and vivado synthesis guides for different encoding styles for BRAM and DMEM based RAMs/ROMs.