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: 
Highlighted
Visitor kevinneilson
Visitor
14,288 Views
Registered: ‎09-11-2014

Vivado Pulls Registers out of BRAM

How do I prevent Vivado (2014.3.1) from pulling the output registers out of my BRAMs?  It loves to do this, and it's almost always detrimental.  I'm inferring the BRAMs.  Usually it pulls out the registers and puts them into slices, and then I fail timing because this adds about 1ns to the clk->out time of the BRAM and then there is the fabric routing time to get to the flop.  And the setup time.

 

The worst is when I have an SRL delay line after the BRAM, and Vivado pulls the register out of the BRAM and adds another cycle of delay to the SRL.  This is just crazy.  It just makes timing worse for no reason at all.

 

Is there some directive I could use to prevent this?  I'd rather not instantiate BRAM primitives.

 

I enclosed a picture.  You can see that DOB_REG (see lower left corner of picture) on the BRAM is set to 0, so the output register is not enabled.  Vivado instead pulls that register into the fabric ("srlopt"). 

Tags (3)
bram_reg.jpg
0 Kudos
17 Replies
Scholar dwisehart
Scholar
14,282 Views
Registered: ‎06-23-2013

Re: Vivado Pulls Registers out of BRAM

I would interested to hear also, because I went to hand instantiating all of the FIFO's and BRAM's in our designs so that I could avoid problems like this.

 

Daniel

 

0 Kudos
Xilinx Employee
Xilinx Employee
14,250 Views
Registered: ‎09-20-2012

Re: Vivado Pulls Registers out of BRAM

Hi,

 


Please refer to pages-98,99 of http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_4/ug901-vivado-synthesis.pdf for coding examples to infer “Block RAM with Optional Output Registers” in Vivado synthesis.

Make sure that you are following the same coding style.

 

Thanks,

Deepika.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Visitor kevinneilson
Visitor
14,243 Views
Registered: ‎09-11-2014

Re: Vivado Pulls Registers out of BRAM

Yes, I'm following the template in the synthesis guide.  It's not an inference problem.  Sometimes Vivado puts the output registers inside the BRAM.  But sometimes its heurstics thinks timing will be better if it pushes them out into slices.  I want a way to prevent it from doing that.

0 Kudos
Scholar dwisehart
Scholar
14,235 Views
Registered: ‎06-23-2013

Re: Vivado Pulls Registers out of BRAM

Agreed: consistently doing what is in the synthesis guide sometimes gives the desired result and sometimes it does not.  I know turning "flatten hierarchy" in the synthesis settings to "none" is helpful in many cases but not all cases.  It would be nice to get this fixed.

 

In the end I just put my BRAM and FIFOs into separate modules with hard coded RAMBnnE1 and FIFOnnE1 macros, as shown by UG768.  The parameters for output registers are DOA_REG and DOB_REG on pg 410 in version 14.7 of the same guilde for RAMB36E1.

 

Daniel

 

0 Kudos
Visitor kevinneilson
Visitor
14,226 Views
Registered: ‎09-11-2014

Re: Vivado Pulls Registers out of BRAM

I could instantiate BRAM primitives but it's not too practical, as I have a lot of RAMs of parameterizable widths/depths and some asymmetric RAMs.  And the UNISIMs slow down the sim considerably.  I also have a lot of ROMs I initialize with $readmemh(), and if I used BRAM primitives, I'd have to do something awkward to initialize them or use CoreGen, which I really want to avoid.

0 Kudos
Visitor eia273905826
Visitor
14,201 Views
Registered: ‎02-12-2015

Re: Vivado Pulls Registers out of BRAM

Have you tried putting "KEEP" attributes on the BRAM inferred signals?

--
There are only 10 types of people around - those who understand binary and those who don't.
0 Kudos
Teacher muzaffer
Teacher
14,169 Views
Registered: ‎03-31-2012

Re: Vivado Pulls Registers out of BRAM

Unless one instantiates the BRAMs with a keep_hierarchy property or uses coregen IP (which probably does something similar), Vivado does this for you if it thinks pulling the register into the fabric is going to be beneficial timing-wise. The only way to prevent this is to add another pipeline register at the output which would give Vivado the flexibility of placement. This add a cycle of latency but the result is better timing (usually).

 

<rant>

Vivado's placer leaves a lot to be desired. Here is to hoping that they would improve it in 2015.1 a little.

</rant>

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Scholar dwisehart
Scholar
14,159 Views
Registered: ‎06-23-2013

Re: Vivado Pulls Registers out of BRAM


muzaffer wrote:

<rant>

Vivado's placer leaves a lot to be desired. Here is to hoping that they would improve it in 2015.1 a little.

</rant>


I have to agree.  We manually place or pblock place almost everything for Vivado.  There are many complete designs that Vivado would declare unworkable, even trying the different implementation strategies.

 

Daniel

 

0 Kudos
Visitor kevinneilson
Visitor
14,146 Views
Registered: ‎09-11-2014

Re: Vivado Pulls Registers out of BRAM

No, but I don't think that would do what I want.  If you put a KEEP before the register, that would probably prevent Vivado from putting the register inside the BRAM.  But I want the Vivado to put the register INSIDE.  Putting a KEEP on the register output doesn't make sense because that's going to be in the fabric anyway.

0 Kudos
Visitor kevinneilson
Visitor
11,922 Views
Registered: ‎09-11-2014

Re: Vivado Pulls Registers out of BRAM

I see why Vivado thinks that sometimes it's better to pull the register out, but its heuristics are all messed up and sometimes it pulls them out when it really shouldn't (i.e., most of the time).  It vastly underestimates the net delay to the fabric flipflops.

 

And putting an extra FF on the output often doesn't work either, like in the example I gave before.  I can have an 10-cycle-delay SRL delay line after the BRAM, and Vivado will pull the register out of the BRAM and make the SRL have a delay of 11 cycles.  It just took a successful design and and made it a failure.  

0 Kudos
Teacher muzaffer
Teacher
11,917 Views
Registered: ‎03-31-2012

Re: Vivado Pulls Registers out of BRAM

>> I can have an 10-cycle-delay SRL delay line after the BRAM, and Vivado will pull the register out of the BRAM and make the SRL have a delay of 11 cycles.

There is the rub; an SRL is not a register (although it's storage), its placement is different, its setup constraint is different. You need to make sure the pipeline registers are actually DFFs (FDRE) and not SRL. Having two sets of registers at the output of memory makes life quite easy and allows Vivado to keep one of them as the built-in output register.

 

Put a shreg_extract attribute with a value of no at the registers you want to use for pipelining and save SRLs for delay lines. It's also beneficial to make the first stage of a delay line a real DFF too (if you are into instantiating parameterized delay lines in your designs that is)

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Visitor kevinneilson
Visitor
11,909 Views
Registered: ‎09-11-2014

Re: Vivado Pulls Registers out of BRAM

The SRLs are all inferred.  I could use the SHREG directive to make sure there is an FF at the front of the SRL, but I think Vivado would still pull the register out of the BRAM and use that for the FF in front of the SRL.  What it should be doing is pulling cycles out of the SRL and moving them backward, but it always wants to move the BRAM register forward.  But yes, maybe putting extra FFs after the BRAM with DONT_TOUCHes on them would work, but what I'd really like is to improve the timing without changing functionality, which I could do by getting the FFs to stay inside the BRAM.  The SRL example is just one. 

 

Vivado apparently thinks the net delay to the FF will be very short.  But here's what happens.  It moves the register out of the BRAM into the fabric.  Now my clk->out on the BRAM goes to something like 1.8ns.  With the FF setup time I have over 2ns, without the net delay.  Then if the net delay is over about 600ps, which it often is, my 2.7ns period is exceeded and timing fails.

0 Kudos
Voyager
Voyager
11,843 Views
Registered: ‎05-31-2012

Re: Vivado Pulls Registers out of BRAM

why don't you use the DOA_REG = 1  property in the bram?

0 Kudos
Scholar dwisehart
Scholar
11,834 Views
Registered: ‎06-23-2013

Re: Vivado Pulls Registers out of BRAM

This has been discussed: because this is inferred BRAM.  In inferred BRAM there is no available DOA_REG.

0 Kudos
Voyager
Voyager
11,821 Views
Registered: ‎05-31-2012

Re: Vivado Pulls Registers out of BRAM

maybe placing a constraint on the max delay from the output port of the BRAM

 

set_max_delay 2 -from [get_ports out*]

0 Kudos
Visitor kevinneilson
Visitor
11,806 Views
Registered: ‎09-11-2014

Re: Vivado Pulls Registers out of BRAM

That might work.  I'll have to try it out.  I read through some documentation and it might be phys_opt that's pulling these out and there may be a way to turn off the option.  Not sure yet.

0 Kudos
Visitor kevinneilson
Visitor
4,610 Views
Registered: ‎09-11-2014

Re: Vivado Pulls Registers out of BRAM

Deepika,

You have a signature line with obvious advice like "Google your question before posting."

 

Here's some obvious advice for you:

- Read the question before answering.

- Don't point someone to a language template when it doesn't help and think that you've answered the question.

 

0 Kudos