UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
2,606 Views
Registered: ‎01-23-2018

[Doubt] BRAM/LUTRAM

Jump to solution

Hi,

 

when I'm doing the synthesis I'm reading some messages like:

 

INFO: [Synth 8-5544] ROM "XXXX" won't be mapped to Block RAM because address size (4) smaller than threshold (5)
INFO: [Synth 8-5545] ROM "XXXX" won't be mapped to RAM because address size (32) is larger than maximum supported(25)

INFO: [Synth 8-5546] ROM "XXXX" won't be mapped to RAM because it is too sparse

 

 

 

This will be a problem or it just says that he will implement it as LUTRAMs of FF. If is just info that didn't affect how my project works I have no problem, but if this disable that signals in some way it will be a problem.

 

 

Thanks

0 Kudos
1 Solution

Accepted Solutions
Scholar richardhead
Scholar
3,106 Views
Registered: ‎08-01-2012

Re: [Doubt] BRAM/LUTRAM

Jump to solution

This one is a bit of a concern:

INFO: [Synth 8-5545] ROM "XXXX" won't be mapped to RAM because address size (32) is larger than maximum supported(25)

 

32 bits is a rather large memory, why do you need such a large address bus? Thats a 4GB address space, and will definitaly not fit inside any FPGA available.

11 Replies
Scholar richardhead
Scholar
3,107 Views
Registered: ‎08-01-2012

Re: [Doubt] BRAM/LUTRAM

Jump to solution

This one is a bit of a concern:

INFO: [Synth 8-5545] ROM "XXXX" won't be mapped to RAM because address size (32) is larger than maximum supported(25)

 

32 bits is a rather large memory, why do you need such a large address bus? Thats a 4GB address space, and will definitaly not fit inside any FPGA available.

Explorer
Explorer
2,564 Views
Registered: ‎01-23-2018

Re: [Doubt] BRAM/LUTRAM

Jump to solution

Hi @richardhead,

 

thanks for replying my code will use an external memory device so it won't be a problem with access to that range of address, I will look as soon as possible if I'm creating something wrong with that signal.

 

 

Thanks,

 

Joel

0 Kudos
Scholar richardhead
Scholar
2,556 Views
Registered: ‎08-01-2012

Re: [Doubt] BRAM/LUTRAM

Jump to solution
But the message implies you're trying to synthesis a very large ram. If you are using an external ram, then you shouldnt be trying to create one.

Why not post some code?
Explorer
Explorer
2,495 Views
Registered: ‎01-23-2018

Re: [Doubt] BRAM/LUTRAM

Jump to solution

Hi @richardhead,

 

 

thanks for helping. I'm not allowed to share code due it is confidencial, anyways I will try to run with that warning and I will see how it works.

 

 

Regards,

 

Joel

0 Kudos
Scholar richardhead
Scholar
2,485 Views
Registered: ‎08-01-2012

Re: [Doubt] BRAM/LUTRAM

Jump to solution
I highly doubt there is anything you can post that isnt already on the internet. Small bits of memory generation code are pretty generic and unlikely to cause any issues.
0 Kudos
Visitor jmhbfe
Visitor
1,893 Views
Registered: ‎05-24-2018

Re: [Doubt] BRAM/LUTRAM

Jump to solution

I'll give you some sample code that illustrates the bogus Info 8-5545:

`timescale 1ns / 1ps
module test #(parameter SIZE1 = 26, SIZE2 = 25) (
	input clk,
	input rstn,
	input cc,
	output we1, we2,
	input [SIZE1-1:0] dd1,
	input [SIZE2-1:0] dd2);
	
	dut #(.SIZE(SIZE1)) dut1 (
		.clk(clk), .rstn(rstn), .cc(cc), .we(we1), .dd(dd1));
	dut #(.SIZE(SIZE2)) dut2 (
		.clk(clk), .rstn(rstn), .cc(cc), .we(we2), .dd(dd2));
endmodule

module dut #(parameter SIZE=26) (
    input clk,
    input rstn,
	
    input cc,
	
    input  [SIZE-1:0] dd,

    output reg we
);

	reg [1:0] state;

    always @(posedge clk or negedge rstn) begin
        if (!rstn) begin
            we                   <= 1'b0;
				state <= 3'd0;
        end else begin
			case (state)
				3'd0: begin
					if(cc) begin	// new one, could be last one, write it regardless
						we <= 1'b1;
						state <= 3'd1;
					end
				end
				3'd1: begin
					we <= 1'b0;
					if(!cc) begin	// wait for start to finish
						if(dd == 0) begin	// last one, could be only one
								state <= 3'd2;
						end
					end
				end
				
				3'd2: begin
					if(cc) begin	// abort abort abort!
						if(dd == 0) begin	// plain abort
							we <= 1'b1;
							state <= 3'd1;
						end
					end else begin
						state <= 3'd0;
					end
				end
			endcase
		end
	end

endmodule

dut is instantiated twice, once with a bus size of 26, once with a bus size of 25.  Synthesize with 2018.1. (Haven't tried 2018.2.)  Default xc7k70tfbv676-1 though it seems the device is irrelevant.  And never mind that the code doesn't do anything useful, it's stripped down from a much larger FSM.

 

Get these two infos:

 

INFO: [Synth 8-5545] ROM "dut1/we" won't be mapped to RAM because address size (26) is larger than maximum supported(25)
INFO: [Synth 8-5546] ROM "dut2/we" won't be mapped to RAM because it is too sparse

 

So tell me how "we" can be interpreted as a ROM with an address size the size of the bus?

Since its value is conditional, I don't see how it can even be interpreted as a ROM.

 

And if you play around with the SIZE parameter, anything over 25 gets "we" complained about as too large.

 

Gotta be bogus.

Observer kerryhj
Observer
1,478 Views
Registered: ‎07-02-2008

Re: [Doubt] BRAM/LUTRAM

Jump to solution

For what it's worth, I'm getting a whole bunch of similar (and seemingly bogus) warnings in my project as well.  Seems like almost every port  is returning this warning (Vivado 2018.3), even some that are not 25 bits wide.

 

INFO: [Synth 8-5545] ROM "fifo_in_data" won't be mapped to RAM because address size (32) is larger than maximum supported(25)
INFO: [Synth 8-5545] ROM "fifo_in_valid" won't be mapped to RAM because address size (32) is larger than maximum supported(25)

 

 

0 Kudos
Highlighted
Explorer
Explorer
1,421 Views
Registered: ‎10-24-2008

Re: [Doubt] BRAM/LUTRAM

Jump to solution

@kerryhj  @jmhbfe I have replicated this problem in 2018.3 using @jmhbfe's source code.  I will open a case with the factory and ask them to create a CR if this issue has not previously been corrected.  I will advise back here as to the response that I receive.

--Quenton

Explorer
Explorer
1,181 Views
Registered: ‎10-24-2008

Re: [Doubt] BRAM/LUTRAM

Jump to solution

@kerryhj@jmhbfeI wanted to provide you an update on this.  Xilinx WTS synthesis experts have agreed that Vivado should not generate these messages in such cases.  They have filed CR-1020770 regarding this issue and have reported this to the development team who will investigate this issue further and take appropriate action.

Thanks for your assistance in documenting the problem so that it could be easily addressed.

--Quenton

0 Kudos
Observer kerryhj
Observer
1,178 Views
Registered: ‎07-02-2008

Re: [Doubt] BRAM/LUTRAM

Jump to solution

Awesome, thanks @qhall!

0 Kudos
Explorer
Explorer
834 Views
Registered: ‎10-24-2008

Re: [Doubt] BRAM/LUTRAM

Jump to solution

@kerryhj @jmhbfe  Just FYI, CR-1020770 has been updated as fixed.  You should thus see this corrected in a future Vivado release.

--Quenton

0 Kudos