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: 
Visitor skyboy10000
Visitor
227 Views
Registered: ‎01-03-2019

2017.4 a question about ultra ram inference and byte width

Jump to solution

Hi,

A warning appeared in synthesis:

WARNING: [Synth 8-5835] Resources of type URAM have been overutilized. Used = 2048, Available = 960. Will try to implement using BRAM.
reason is byte width (1) is not a multiple of 8(data_only) or 9(data + parity)
reason is byte width (1) is not a multiple of 8(data_only) or 9(data + parity)

While I checked the ram model and confirmed that the data width is 64 (as shown below).

 

   parameter               BITS = 64;
   parameter               word_depth = 98304;
   parameter               addr_width = 17;
   parameter                WP_SIZE    = 8 ;
   parameter               WEN_WIDTH = BITS/WP_SIZE;
 
   output [BITS-1:0] Q;
   input CLK;
   input CEN;
   input [WEN_WIDTH-1:0] WEN;  
   input [addr_width-1:0] A;
   input [BITS-1:0] D;
 
(* ram_style = "ultra" *)   reg [BITS-1:0]          mem [word_depth-1:0];

 

So how should I define the data width to infer the uram correctly?

Thanks.

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
210 Views
Registered: ‎03-16-2017

Re: 2017.4 a question about ultra ram inference and byte width

Jump to solution

Hi @skyboy10000,

 

Can you give it a try by applying the switch -max_uram with value around 800- 900 or lesser? (-max_uram switch may help you to reduce your URAM utilization and infer other memory types.)

 

If it does not help, try with the language template of URAM and check you face the same issue or not. (You will find Language templates in flow navigator of Vivado GUI)

 

Also provide the synthesis log (runme.log) to evaluate.

Regards,
hemangd

Don't forget to give kudos and accept it as solution if your issue gets resolved.
5 Replies
Moderator
Moderator
211 Views
Registered: ‎03-16-2017

Re: 2017.4 a question about ultra ram inference and byte width

Jump to solution

Hi @skyboy10000,

 

Can you give it a try by applying the switch -max_uram with value around 800- 900 or lesser? (-max_uram switch may help you to reduce your URAM utilization and infer other memory types.)

 

If it does not help, try with the language template of URAM and check you face the same issue or not. (You will find Language templates in flow navigator of Vivado GUI)

 

Also provide the synthesis log (runme.log) to evaluate.

Regards,
hemangd

Don't forget to give kudos and accept it as solution if your issue gets resolved.
Scholar markcurry
Scholar
181 Views
Registered: ‎09-16-2009

Re: 2017.4 a question about ultra ram inference and byte width

Jump to solution

@skyboy10000

Dumb question - but I'll ask anyway - are you sure you're not overwriting the default parameter value of BITS=64 from the calling module with another value?

The error message that Vivado is returning is perplexing however:

WARNING: [Synth 8-5835] Resources of type URAM have been overutilized. Used = 2048, Available = 960. Will try to implement using BRAM.
reason is byte width (1) is not a multiple of 8(data_only) or 9(data + parity)
reason is byte width (1) is not a multiple of 8(data_only) or 9(data + parity)

A "byte width" to me, by definition is a number of units of (bytes).  So is, by definition, an integral number of bytes.  But why is Vivado reporting the "byte width" as 1 (you're requesting 64 bits = 8 bytes).  

I'm wondering if the Vivado error reporting is misformed, and the reported "1 byte width" is actually Vivado indicating that it thinks the requested data width is 1 bit.

So - if this is the case -  there'd be two problems here:

1.  Vivado error reporting is emitting a misleading error message. (Xilinx issue)

2.  Vivado thinks the RAM data width is 1 bit.  (User/Xilinx issue)

Regards,

Mark

Visitor skyboy10000
Visitor
155 Views
Registered: ‎01-03-2019

Re: 2017.4 a question about ultra ram inference and byte width

Jump to solution

Thanks all.

I found the reason after comparing the ram model with the uram template.

it's due to the code style of the ram model I use.

The assignment is bit by bit actually, as shown below.

  genvar         i,j;
   generate
   for(j=0;j<WEN_WIDTH;j=j+1)
     begin: u0
      for(i=0;i<WP_SIZE;i=i+1)
     begin: u1
        assign next_d[(j*WP_SIZE)+i] = (~CEN & ~WEN[j]) ? D[(j*WP_SIZE)+i] :
                           cur_d[(j*WP_SIZE)+i];
     end

After modifying it as below, the uram inference is ok now.

   genvar         i,j;
   generate
   for(j=0;j<WEN_WIDTH;j=j+1)
     begin: u0
       assign next_d[((j+1)*WP_SIZE)-1:(j*WP_SIZE)] = (~CEN & ~WEN[j]) ? D[((j+1)*WP_SIZE)-1:(j*WP_SIZE)] :
                           cur_d[((j+1)*WP_SIZE)-1:(j*WP_SIZE)];
     end
   endgenerate

0 Kudos
Moderator
Moderator
150 Views
Registered: ‎03-16-2017

Re: 2017.4 a question about ultra ram inference and byte width

Jump to solution

HI @skyboy10000,

 

Good to know your issue has been resolved by following the URAM language template. 

Hence, close this thread my marking it as accepted solution. 

 

Regards,
hemangd

Don't forget to give kudos and accept it as solution if your issue gets resolved.
0 Kudos
Visitor skyboy10000
Visitor
149 Views
Registered: ‎01-03-2019

Re: 2017.4 a question about ultra ram inference and byte width

Jump to solution

Thanks, Mark.

Your comment inspired me to find the real cause.

Anyway, I have to say vivado's warning message is confusing.

0 Kudos