Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Xilinx ISE problem - RAM implemented as distributed instead of block

Status
Not open for further replies.

NikosTS

Advanced Member level 4
Joined
Jan 30, 2017
Messages
119
Helped
1
Reputation
2
Reaction score
2
Trophy points
18
Activity points
1,054
Hello everyone,
As you can see in the title , i have a problem with a memory that I infer as block RAM but it is implemented as distributed leading to excessive resources being used.
The error showing up in Xilinx XST is the following :
INFO:Xst:3218 - HDL ADVISOR - The RAM will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features.

The read operation of the RAM is (pretty much ) this one :

Code Verilog - [expand]
1
2
3
4
5
6
always @(posedge clk) begin
                    if ( counter < 972 ) begin  // RAM <banks> has 972 banks of 5 bits each
                        read_reg <= banks[counter][max_error_bits -1 : 0];
                        counter <= counter + 1;
                    end
begin


If i understand correctly , the tool says that i read from the memory asynchronously but i am pretty sure i do it synchronously. Is there something that i am missing?

Thank you in advance,
Nikos
 
Last edited by a moderator:

what about the write?

perhaps it is the declaration (eg, using 972 or 1024 vs 1023) or the extra [max_error_bits-1:0]. I think the latter is ok and the former is not ok. ISE is really bad at explaining why something isn't a BRAM.
 

The write operation is also in the same always block, but it is a bit more complicated that's why i dont include it. The important thing is that i write only at 1 address per clock cycle, so that shouldnt be a problem for the RAM to be interpreted as distributed.
Anyway, back to the read operation, do you suggest to change the depth to a power of 2 ( 1023 for example ) and write to/read from the first 972 addresses?

Thank you
 

I've had issues in the past with something like [0:1024] not being detected as any type of BRAM, while [0:1023] would be detected correctly.
 

Well, i changed the vector declaration to : [width-1 : 0 ] banks [ 0 : 1023 ] ( where width=5 ) and still got the same problem. Any other ideas?
 

This post on the Xilinx forum has the template produced for an inferred RAM in XST. (I don't have XST installed so can't verify).
http://forums.xilinx.com/t5/Synthesis/Distributed-RAM-automatic-inference-in-XST/td-p/221553


Code Verilog - [expand]
1
2
3
4
5
6
7
8
always @(posedge <clock>) begin
      if (<enableA>) begin
         if (<write_enableA>)
           <ram_name>[<addressA>] <= <input_dataA>;
           <output_dataA> <= <ram_name>[<addressA>];
      end
      if (<enableB>)  <output_dataB> <= <ram_name>[<addressB>];
   end


The takeaway here is there is no complicated comparisons or other code in the template. Just simple enableA and enableB placeholder. I would avoid having anything but a single signal name in those <xxxxxx> spots. Having comparisons and other signals (e.g. counter) buried within your inferred RAM code is more likely to result in problems.

Also on that page I referenced is the use of the RAM_STYLE attribute, which can force the type of inferred RAM used.
 

you could try using only one index: "read_reg <= banks[counter]" and then resize the bus in an assign statement outside of the always block.

and also double check that the ram isn't accessed anywhere else -- eg in simulation-only code.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top