cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
kami
Participant
Participant
1,172 Views
Registered: ‎03-18-2017

Setup time slack in BRAM ENARDEN port

Hi,

I take this timing report after the implementation.

Screenshot_7.png

 

 

 

 

 

I read some posts about ENARDEN port of RAMB36E1 but turning off the bram power optimization didn't solve the issue. Can you help me for fixing the problem?

Thanks,

Kami

 

0 Kudos
8 Replies
blindobs
Adventurer
Adventurer
1,131 Views
Registered: ‎09-13-2018

Hi,

What device and speed grade are you using ? Your BRAM clock is 400 MHz so its high frequency, not all devices BRAM can achieve this values. Also note that your logic is 3 levels depth additional logic pipeline to shallow logic levels registers can help. Anyway do you really need to turn on/off ram via ENARDEN port for powersaving ?

kami
Participant
Participant
1,124 Views
Registered: ‎03-18-2017

Hi, Thanks for reply.

I'm using Artix 7 200T with -1 speed grade in Nexys Video Board. Actually my BRAM clock is 200 MHz but in timing report, it shows 400MHz. I assumed BRAM doubles the clock in itself for some reason.

I'm using SDP BRAM and its A port is always enabled and I read unnecessary power optimizations can be result to this problem and I turned off this setting.

0 Kudos
blindobs
Adventurer
Adventurer
1,110 Views
Registered: ‎09-13-2018

BRAM doesn't doubles the clock by itself. Doubling frequency might be caused by control logic using falling edge of clock while BRAM clocks with rising edge. If BRAM is alwayse enabled why not drive ENARDEN with constant '1' ?.

Also note that for speed grade -1 BRAM max frequency in ARTIX-7 device.

bram.png

0 Kudos
kami
Participant
Participant
1,098 Views
Registered: ‎03-18-2017

Hi @blindobs,

In block memory generator, I can only select "always enable" or "use enable pin" options. I tried use enable pin option too with driving it with constant 1 but it didn't solve the problem. Driver of ENARDEN port of the RAMB36E1 block in BRAM is adjusted by the tool.

I'm using 200MHz in my design with using only rising edge of the clock. I think the control logic that you mentioned is internal control logic of the BRAM, right?

0 Kudos
blindobs
Adventurer
Adventurer
1,077 Views
Registered: ‎09-13-2018

Can you share simple example projekct with this error ? It's strange behaviour and points out rather to some clock constraints error as frequency is doubled.

0 Kudos
1,068 Views
Registered: ‎01-22-2015

@kami 

I'm sure that you and blindobs will get to the bottom of the clock frequency issue.

I just wanted to say that I observe NoBramPowerOpt is not working in Vivado v2018.3 – and it hasn’t been working since at least Vivado v2017.3.  That is, BRAM power optimization takes control (or at least partial control) of BRAM ENA/ENARDEN, regardless of anything we do.
NoBramPowerOpt.jpg

I hope a Xilinx moderator will see this post and submit a change request to get NoBramPowerOpt working.

Cheers,
Mark

0 Kudos
avrumw
Guide
Guide
1,052 Views
Registered: ‎01-23-2009

Actually my BRAM clock is 200 MHz but in timing report, it shows 400MHz.

We need to understand this better - showing the detailed timing report of one of the failing paths will help.

The BRAM does not do any kind of clock doubling. You say your clock is 200MHz, but the requirement on this path is 2.5ns, which means that it is trying to meet a one half clock cycle timing requirement. We need to understand why - is either the flip-flop driving the RAMB or the RAMB itself clocked on the falling edge of the clock?

But even if this is a simple error due to a clock inversion - even at a full clock period, this path would fail. So you will need to find other solutions. One thing to look at is how many RAMs this enable signal enables... RAMs are big (physically large blocks on the die) - fanning out a single signal to multiple RAMs means large net delays to reach the "farther" RAMs. The largest fanout on this path is 41 - if you are trying to go to 40+ RAMB cells with a common control signal, there is no way this is going to work at any reasonable clock rate. You will have to split up (and possibly pipeline) your RAM control signals if you are trying to drive large numbers of RAMs in parallel.

Avrum

0 Kudos
kami
Participant
Participant
1,015 Views
Registered: ‎03-18-2017

Hi all, sorry for the delayed reply.

@blindobs, I'm afraid i can't share the project. But I have a slightly big frame buffer as BRAM and this leads to large fanout as @avrumw said. After markg@prosensing.com's reply, i totally reduce the frame buffer. NoBramPowerOpt option change nothing in Vivado 2018.2 as you said.

I still have some small BRAM memories in my design and i haven't run the implementation/timing report yet.

Thank you all, i will introduce you about the timing results.

0 Kudos