cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
m.gagliardi
Observer
Observer
640 Views
Registered: ‎04-08-2019

Route design never gets to end

Jump to solution

Hi,

I have a problem with the time of design implementation.

As shown in Figure 1, I have an input clock  on differential pins, this clock is 125 MHz and I use an MMCM synthesized  by the Clocking Wizard  to bring it up 250 MHz and provide it to a logic (I use the clock for processes) . I use  BUFG primitives for input and output of MMCM and also I use BUFG to bring the clock to ILA. The route design implementation is about 50 minutes.

Now, I need to produce other 3 programmable clock signals and for this I have synthesized an MMCM with 4 clock output; one of these clocks has to be lower than 6 MHz (the lowest allowed value of MMCM).

The design that I defined is shown in Figure 2 ; the input of MMCM is always guided by a BUFG, 3 output clocks of MMCM are linked  to BUFG (each one to a single BUFG) and 1 output clock (that lower than 6 MHz) is linked to BUFGCE_DIV (to perform a division of clock frequency).   The output clocks are provided to a logic.    

The BUFG and BUFGCE_DIV  primitives are also replicated to bring the clocks to ILA  for monitoring. (BUFGCE_DIV primitive is included in GB_BUF_3 and BUFG_CLK IP cores in Figure 2)

The running route design never gets to end.

Could anyone help me?

Figure_1.png
Figure_2.png
0 Kudos
1 Solution

Accepted Solutions
dsheils
Moderator
Moderator
477 Views
Registered: ‎01-05-2017

You will need to do some path analysis to see why those TIMING-6 violations are occurring. Run report_methodology and it will list that violation - it will also give you the report_timing command to see what paths are between those clocks.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

8 Replies
syedz
Moderator
Moderator
624 Views
Registered: ‎01-16-2013

@m.gagliardi 

 

Do you mean the tool got hung during router? Check the runme.log file in .runs/impl_1/ folder and check the timestamp of the file if it is getting updated.

Share the runme.log file here. 

I suspect the changes in the design have caused timing violation (mostly hold) so the router is taking longer runtime to close the timing. 

Check UG1292 which should help in timing closure: 

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_2/ug1292-ultrafast-timing-closure-quick-reference.pdf 

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- 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.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
m.gagliardi
Observer
Observer
555 Views
Registered: ‎04-08-2019

Hi, thanks for answer.

The tool doesn't stop but the running route_design go head for hours and hours and I am forced to stop it. Indeed I can't share the file according your request because the folder impl_1 is empty (the tool doesn' t complete the work).

0 Kudos
dsheils
Moderator
Moderator
548 Views
Registered: ‎01-05-2017

Hi @m.gagliardi 

If the impl folder is empty are you saying that the tool does not even go through opt_design and place_design either?

Can you load the post_synth DCP and then run opt_design, place_design and route_design? (or start from whatever the last DCP is available)

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
m.gagliardi
Observer
Observer
529 Views
Registered: ‎04-08-2019

The tool performs this sequence after synthesis: initializing Design--> Running opt_design --> Running place_design --> Running phys_opt_design --> Running route_design

On Running route_design the tool goes head for hours. When I cancel the process to stop it, the files in folder are canceled but the DCP files of synthesis and first 3 steps of Implementation are produced; file runme.log (in attach) also is produced, I launched again the implementation and during Running route_design phase I get the file. 

0 Kudos
dsheils
Moderator
Moderator
520 Views
Registered: ‎01-05-2017

Hi @m.gagliardi 

If you look at the runme.log on line 871 you will see that the Intermediate Timing Summary at the start of route has plenty of positive setup slack but the worst hold violation is pretty large at -1.627ns. This will result in route_design having to do hold fixing and it will try to do this at the expense of setup margin. This can cause long runtimes. There is also some CLB congestion reported also.

You're going into route_design with a very high Hold violation. You need to go back and address this at an earlier stage in your design. Like @syedz  mentioned, UG1292 is a very good quick reference guide for timing closure. It will outline the analysis steps you should be doing. Any questions just ask us here.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
m.gagliardi
Observer
Observer
486 Views
Registered: ‎04-08-2019

Hi,

I start with UG192 and I produced the report_failfast (in the attach).

In the timing section I see problems on Timing-6  and Timing-7 , I have seen on UG906 Appendix A that these issues can be caused by a  no common primary clock (Timing-6) and a no common node (Timing-7). 

But I don't understand because of in my design the clocks are all derived by the same clock and produced by the same MMCM

report_failfast.png
0 Kudos
dsheils
Moderator
Moderator
478 Views
Registered: ‎01-05-2017

You will need to do some path analysis to see why those TIMING-6 violations are occurring. Run report_methodology and it will list that violation - it will also give you the report_timing command to see what paths are between those clocks.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

m.gagliardi
Observer
Observer
354 Views
Registered: ‎04-08-2019

Hi,

I ran report_methodology and I have seen the design timing violation, after I applied the command defined in the report in the constraint file and restarted the implementation. This now get time about 30-40 minutes.

Thanks very much for the help. 

 

0 Kudos