cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
10,806 Views
Registered: ‎02-10-2015

BRAM usage issue 2013.4 vs 2014.4

I am seeing the different number on BRAM utlization 

 

2013.4 is giving better result compare to 2014.4.

-  2013.4 : 16.5

-  2014.4 : Complete memory is implemented in LUTs

 

Attached is the memory module. Someone can try synthesis in two different versions of Vivado and help me explaining the behavior.

0 Kudos
11 Replies
Highlighted
Adventurer
Adventurer
10,796 Views
Registered: ‎02-10-2015

To me this seems to be a bug in 2013.4 and got fixed later.

 

Any one have exact info - on the issue.

0 Kudos
Highlighted
Moderator
Moderator
10,788 Views
Registered: ‎01-16-2013

Hi,

I will try to synthesis in both the version and update.

But I have one question are you using same synthesis settings for both the versions?

Thanks,
Yash
0 Kudos
Highlighted
Adventurer
Adventurer
10,767 Views
Registered: ‎02-10-2015

Yes, default settings in both

0 Kudos
Highlighted
Moderator
Moderator
10,742 Views
Registered: ‎01-16-2013

Hi,

Just now I have created the project using both vivado version and I am also able to see the difference.

If you check Vivado 2014.4 runme.log and compare with 2013.4 log you will see 2 major differences.
Register count and RAM count. There is one warning in Vivado 2014.4 that infeasible RAM style.

WARNING: [Synth 8-3463] Infeasible ramstyle = block set for RAM ram_core_32_reg,trying to implement using LUTRAM

I am looking into this if this is issue with Vivado 2014.4. I will update this thread with proper info.

Thanks,
Yash
0 Kudos
Highlighted
Scholar
Scholar
10,719 Views
Registered: ‎06-23-2013

Making it clear if you want read first or write first allowed the attached code to infer BRAM in 2014.1.

 

Daniel

2015-04-28_16-17-16.png

 

 

0 Kudos
Highlighted
Scholar
Scholar
10,717 Views
Registered: ‎06-23-2013

Here is the same code again, in for-loop mode, which is perhaps a little easier to read because it is not so long.

 

Daniel

 

0 Kudos
Highlighted
Adventurer
Adventurer
10,530 Views
Registered: ‎02-10-2015

@yashp

 

Any info on difference - 2013.4 and 2014.4 gives different result.

 

Not sure if you have checked on 2015.1.

0 Kudos
Highlighted
Adventurer
Adventurer
10,339 Views
Registered: ‎02-10-2015

@yashp 

Any further info. Did you test using 2015.1.

Was this is issue in 2013.4 or in 2014.4?

0 Kudos
Highlighted
Adventurer
Adventurer
10,321 Views
Registered: ‎02-10-2015

I checked it uses LUTs in Vivado 2015.1

0 Kudos
Highlighted
Adventurer
Adventurer
7,731 Views
Registered: ‎02-10-2015

with the attached file - I could get this implemented in BRAM using 2015.1.

 

Not sure if this is correct behavior. I just did some rearrangement of code.

 

Question - it uses 33 RAMB18 (approx double then what I expect) for a 258 (width) & 1024 (depth) with Byte enable.

0 Kudos
Highlighted
Observer
Observer
7,654 Views
Registered: ‎03-02-2015

You're instantiating your "ram" module 33 times, and each one infers a single 1Kx8 memory, so that's how you end up with 33 copies of RAMB18. The tools might not be smart enough to reliably (or ever) merge inferred RAMs across modules, even though it's perfectly obvious you could pack two 1Kx8 into a single RAMB18.

 

The solution is to rewrite or replace your "ram" module so it implements multiple byte lanes inside.  UG901 (Vivado Synthesis) has this link to a ZIP file full of inference examples for block RAM (and other common cases where you want to reliably infer a particular FPGA resource):

 

https://secure.xilinx.com/webreg/clickthrough.do?cid=363306

 

I'd recommend rewriting your wrapper to use one of the byte-write-enable block RAM modules in here.  It looks like you should probably use a read-first mode module, but I'd review carefully to be sure.

0 Kudos