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
9,810 Views
Registered: ‎06-03-2014

Timing problems with signals routed to scattered BRAM

Jump to solution

Hi,

i have a question regarding a timing problem. First i give a short explanation about the affected design:

  1. The design uses BRAMs and 4 DSPs to sample and summarize ADC values with a frequency of 450 MHz resulting. The data is transferred on 2 parallel buses providing each a sample on the rising and falling edge. The system clock is 125 MHz (450/(2*2) = 125).

  2. The sample depth is 262144 and each sample is 28 bit width. The 28 BRAMs (each with a width of 1 bit) are combined to a BRAM with 28Bit width and 32768 bit depth. The 28Bit BRAMs are cascaded to a BRAM with 28Bit width and 65536 bit depth.

  3. Each of the cascaded BRAM is connected to a DSP, every clock cycle a read operation and a write operation is performed. (The read and write operations are pipelined, the latency prevents a possible read/write collision.)

The timing problem usually occurs at BRAM signals (WR, RD or EN signals). I think this occurs because a lot of BRAM (44% of the FPGA) is used. The distance to the relative “far away” BRAMs compared to the relative near BRAMs causes a big routing delay.

I tried to compensate this with a chain of latches/repeaters on the BRAM signals to increase the latency but also split up the routing delay over several clock cycles. This approach worked in the past and all timing constraints were met.

Recently I used the same custom IP core with the BRAMs in another design with PCIe instead of a Microblaze system and the timing constraints are always violated. I don’t know why Vivado can’t route it this time with all timing constrains met and need advice.

I appended the timing reports for the old design (constraints met) and the new design (constraints violated) if needed. I also appended the BRAM component VHDL code and block diagram.

Regards,

Andreas

Tags (2)
cmp_bram.png
0 Kudos
1 Solution

Accepted Solutions
Professor
Professor
17,408 Views
Registered: ‎08-14-2007

Re: Timing problems with signals routed to scattered BRAM

Jump to solution

The big difference seems to imply that in the case where constraints were met, registers were duplicated.  In the case where they were not met I see a net with a fanout of 56 implying the register was not duplicated.  You may want to check the synthesis options for the working vs non-working designs to see if the working one enables register duplication and the non-working one doesn't.  Also, I'm not sure about Vivado, but in ISE I found that "equivalent register removal" would undo the register duplication, so it made sense to disable it.  You could always explicitly replicate the registers in your source, but it shouldn't be necessary if the tool options are set correctly.

-- Gabor

View solution in original post

0 Kudos
3 Replies
9,809 Views
Registered: ‎06-03-2014

Re: Timing problems with signals routed to scattered BRAM

Jump to solution

The other 3 attachements.

0 Kudos
Professor
Professor
17,409 Views
Registered: ‎08-14-2007

Re: Timing problems with signals routed to scattered BRAM

Jump to solution

The big difference seems to imply that in the case where constraints were met, registers were duplicated.  In the case where they were not met I see a net with a fanout of 56 implying the register was not duplicated.  You may want to check the synthesis options for the working vs non-working designs to see if the working one enables register duplication and the non-working one doesn't.  Also, I'm not sure about Vivado, but in ISE I found that "equivalent register removal" would undo the register duplication, so it made sense to disable it.  You could always explicitly replicate the registers in your source, but it shouldn't be necessary if the tool options are set correctly.

-- Gabor

View solution in original post

0 Kudos
9,772 Views
Registered: ‎06-03-2014

Re: Timing problems with signals routed to scattered BRAM

Jump to solution

Hi Gabor,

 

thank you for your advice. It really helped and i added max_fanout constraints to my hdl. I did not add the "keep" attribute but disabled the "equivalent register removal" in the synthesis settings of vivado.

After a few iterations i added the "max_fanout" to all relevant signals and reduced the path delay via replication as you said. I plan to add the "keep" constraint in the hdl to the signals with the "max_fanout" constraint but for a first try the global settings will do the job.

Now i encountered a new problem, a delay that showed up since i added the max_fanout constraints:

 

The design contains an iteration counter for the state machine that controls the sample and summarize process. This counter is only used inside the state machine to determine the end of the summarize process.

(I also route this signal to a register in which can be accessed by the axi interface of the IP core for debug purpose.)

 

In my last timing report i got a 5.399ns path increase in this counter:

SLICE_X125Y100       FDRE (Prop_fdre_C_Q)         0.223     4.762  r  /SUMMARIZE0/cmp_sum_fsm0/it_count_reg[0]/Q
                                        net (fo=4, routed)                     5.399    10.162    /SUMMARIZE0/cmp_sum_fsm0/Q[0]

 

I can't find an explaination why a simple counter has such a big delay.

 

Regards,

 

Andreas

 

0 Kudos