cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
vgokhale
Explorer
Explorer
9,782 Views
Registered: ‎10-25-2011

Registering to meet timing does not work

Jump to solution

Hello,

 

I have a fairly large design on the Zynq (specifically, the XC7Z045 on the ZC706 dev board). It occupies 89% of DSP slices,  37% of registers, 39% of LUTs and 10% RAM36.

 

I have two clock domains in the design. One is the AXI clock (clock at which the AXI interconnect runs) that drives the AXI DMA engine (4 engines) and sends a data stream to the PL. This is at 142 MHz and meets timing. The second clock is for our custom IP for which the target is 250MHz.

 

The problem is that one data bus in the design does not meet timing on some of its bits. When I open up the Timing analysis and display one of these paths on the "Device" tab in PlanAhead, I see that it is quite spread out. I've attached a view of one of the paths here. Others are similar.

 

The attached screenshot is after registering the outputs. Before registering the outputs, the net delay was pretty long from a register to a MUX. After adding registers on this path, the tool simply puts all registers togeher in the same place as before. The net delay from the final register to the MUX is still very long. Shouldn't the tool equally space these registers out on that path? Otherwise what is the point of adding registers?

 

Are there any coding styles that can fix this? I have already read a few threads here that talk about tweaking synthesis and implementation parameters to improve timing and I have done that.

Screen Shot 2014-03-23 at 7.23.26 PM.png
0 Kudos
1 Solution

Accepted Solutions
driesd
Xilinx Employee
Xilinx Employee
16,205 Views
Registered: ‎11-28-2007

Hi Vgokhale,

 

in addition to the timing path or timing report (.twr file), would it be possible to share the related code?

The reason why I'm asking this is because I'm looking for a way to optimize your code. If you just copy paste the related lines of code to this timing path, that's sufficient.

 

Just looking at your screenshot: it actually doesn't look that spread out to me, but I do see quite a lot of logic levels (lookup tables in the path).

In addition, I see that the source is "acker_/src_pack_data_*" and the destination "pack_mem32_into_sys16_/sys_data_*": it is a general guideline to always register the outputs of a module. This doesn't seem to be the case.

Adding pipeline registers will most likely solve your issue as it cuts your path in half or less.

 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.

View solution in original post

0 Kudos
3 Replies
athandr
Xilinx Employee
Xilinx Employee
9,768 Views
Registered: ‎07-31-2012

Hi,

 

The tool decides the most optimum placement based on the priority of the other logic placement also.

 

However in such cases you can manually move the registers around where you want to place them and try routing.

 

However i cannot see if the Timing violation is Setup or Hold violation? Can you show the full path delay analysis?

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.
0 Kudos
driesd
Xilinx Employee
Xilinx Employee
16,206 Views
Registered: ‎11-28-2007

Hi Vgokhale,

 

in addition to the timing path or timing report (.twr file), would it be possible to share the related code?

The reason why I'm asking this is because I'm looking for a way to optimize your code. If you just copy paste the related lines of code to this timing path, that's sufficient.

 

Just looking at your screenshot: it actually doesn't look that spread out to me, but I do see quite a lot of logic levels (lookup tables in the path).

In addition, I see that the source is "acker_/src_pack_data_*" and the destination "pack_mem32_into_sys16_/sys_data_*": it is a general guideline to always register the outputs of a module. This doesn't seem to be the case.

Adding pipeline registers will most likely solve your issue as it cuts your path in half or less.

 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.

View solution in original post

0 Kudos
vgokhale
Explorer
Explorer
9,733 Views
Registered: ‎10-25-2011
Thank you both for your responses.

driesd, yes the problem was registering. I posted the above screenshot AFTER registering all (or at least I thought all) outputs. There was a part of code I had not worked on that I had forgotten and the signals you see in the image in my original post are with respect to those. Since I had not worked on those, the names of the signals were unfamiliar to me and I misunderstood those as names changed by the tools when retiming.

athandr, the timing violations were all setup violations and all were on this one path. Essentially, what we had was an open source module we borrowed that was entirely combinational in nature. Registering that module helped.

Thank you again for your responses.
0 Kudos