Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎08-01-2014

ISE 14.7 TRCE - debugging "0 paths analyzed, 0 endpoints analyzed, 0 failing endpoints"


My goal is to figure out why I am seeing "0 paths analyzed, 0 endpoints analyzed, 0 failing endpoints" in the timing report for CLKOUT2 from a PLL which has a derived constraint applied to it. I also want to see the timing analyzer actually analyze all the CLKOUT2 paths.

If possible I am hoping to answer the following:

  1. Why are none of the derived clocks (except for the 125 MHz TEMAC clock getting any of their paths analyzed?
  2. And why did the TEMAC get analyzed?
  3. What is the debug approach here? What tool options or constraint am I missing?
  4. Is it impossible to avoid applying downstream timespecs at the outputs of the GBUFS coming off the PLL? (This seems to defeat the purpose of having derived constraints inserted by NGDBuild.


This SPARTAN-6 design consists of a microblaze block (micro) and a custom logic block (main_custom) instantiated at the top of a design called main_top. The system clock oscillator is 200 MHz and is delivered directly from the pads to the micro block where a clock management tile (CMT) is used to derive clocks for DDR3, TEMAC, microblaze and the external logic (DCM pin CLKOUT2 a.k.a. clk100_i). XPS handles all the clocking and constraints via the micro.ucf which is populated with a single timespec to set the clock frequency.

NET "CLK" TNM_NET = sys_clk_pin;
TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 200000 kHz;

The main_top.ucf does not contain any timing constraints. There is no logic being optimized away on the 100 MHz, CLKOUT2 path from the DCM to the custom logic. (The timegrp micro_i_clock_generator_0_clock_generator_0_SIG_PLL0_CLKOUT2 is fully populated in the PCF with BELs)

The CLKOUT2 from the DCM drives a bufg as proven by looking with FPGA Editor:

comp "micro_i/clock_generator_0/clock_generator_0/PLL0_CLKOUT2_BUFG_INST",  site "BUFGMUX_X2Y1",  type = BUFG  (RPM grid X93Y391)

Effort so far...

I have done a lot of web searching for concepts surrounding this problem but am apparently not hitting the right keywords.

The following docs have not brought me any answers either:

Command Line

C:\Xilinx\14.7\ISE_DS\ISE\bin\nt\unwrapped\trce.exe -intstyle ise -v 1 
-tsi main_top.tsi -s 3 -n 1 -xml main_top.twx main_top.ncd 
-o main_top.twr main_top.pcf

Derived Constraints

Derived Constraint Report
Derived Constraints for TS_sys_clk_pin
Constraint Period
Actual Period Errors Paths Analyzed
    Direct Derivative Direct Derivative Direct Derivative
 TS_sys_clk_pin 5.000ns 2.800ns 4.154ns 0 0 0 11598
  TS_micro_i_clk_600_0000MHz180PLL0_nobuf 1.667ns 1.249ns N/A 0 0 0 0
  TS_micro_i_clock_generator_0_clock_generator_0_SIG_PLL0_CLKOUT4 10.000ns 1.730ns N/A 0 0 0 0
  TS_micro_i_clk_600_0000MHzPLL0_nobuf 1.667ns 1.249ns N/A 0 0 0 0
  TS_micro_i_clock_generator_0_clock_generator_0_SIG_PLL0_CLKOUT2 10.000ns 3.124ns N/A 0 0 0 0
  TS_micro_i_clock_generator_0_clock_generator_0_SIG_PLL1_CLKOUT0 8.000ns 6.646ns N/A 0 0 11598 0

Timing Report

Timing constraint: TS_micro_i_clock_generator_0_clock_generator_0_SIG_PLL0_CLKOUT2 = PERIOD
TIMEGRP "micro_i_clock_generator_0_clock_generator_0_SIG_PLL0_CLKOUT2"
TS_sys_clk_pin * 0.5 HIGH 50%;

For more information, see Period Analysis in the Timing Closure User Guide (UG612).
0 paths analyzed, 0 endpoints analyzed, 0 failing endpoints
0 timing errors detected. (0 component switching limit errors)
Minimum period is 3.124ns.
Component Switching Limit Checks: TS_micro_i_clock_generator_0_clock_generator_0_SIG_PLL0_CLKOUT2 = PERIOD TIMEGRP "micro_i_clock_generator_0_clock_generator_0_SIG_PLL0_CLKOUT2" TS_sys_clk_pin * 0.5 HIGH 50%;
Slack: 6.876ns (period - min period limit)
Period: 10.000ns
Min period limit: 3.124ns (320.102MHz) (Trper_CLKA(Fmax))
Physical resource: main_custom_i/board_interface3/receive_fifo/Mram_ram1/CLKA
Logical resource: main_custom_i/board_interface3/receive_fifo/Mram_ram1/CLKA
Location pin: RAMB16_X3Y60.CLKA
Clock network: clk100_i

Other Docs

Unfortunately I am constrained by limitations that prevent me from uploading other design files. I simply cannot take the time to redact all the proprietary info from them.

By: Timothy R Davis, President
0 Kudos
5 Replies
Registered: ‎01-16-2013

Share your UCF file.

Also check for any optimization/trimming warning related to the path/endpoint under consideration.

You will definitely find something in synthesis as well as implementation report.
0 Kudos
Registered: ‎07-16-2008

You mentioned "The timegrp micro_i_clock_generator_0_clock_generator_0_SIG_PLL0_CLKOUT2 is fully populated in the PCF with BELs". So that doesn't sound like a constraint system issue. 


Did you find something out from the TSI report?

Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs.
0 Kudos
Xilinx Employee
Xilinx Employee
Registered: ‎05-14-2008

What are the BEL types in the timegrp micro_i_clock_generator_0_clock_generator_0_SIG_PLL0_CLKOUT2? Are there really valid timing paths existing in this timing group?



Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Registered: ‎05-23-2013

I've had the same problem with the microblaze.


It happens when you have a piece of IP running off of the same clock that's not being analyzed in your TRCE report.  For me, the microblaze clock and the AXI bus clock were shared.  The tools decide that the clocks aren't related and create a timing ignore rule between the AXI clock and the uBlaze clock.  Unfortunately for me, that was also my primary system clock for the rest of my synchronous design, so my period constraint on the clock was overruled by the ignore constraint.


Here's the fix. 

1. Synthesize your embedded design and your planahead design.

2. Open the synthesized design in planahead, and open the timing constraints editor.  

3. Find the offending ignore constraint. 

4. Go into the implementation folder of the embedded system, and find the .ncf file that has the ignore constraint and comment it out.

5. Implement the design and review your TRCE report.  You'll find that the clock domain is now analyzed.


Hope this helps.

0 Kudos
Registered: ‎02-21-2008

I ran into this issue as well.  Thanks to Jared's post for pointing me in the right direction.  In my case it turned out to be the interrupt controller that was creating the problem.  The default configuration for the interrupt controller assumes that the Microblaze clock and the AXI clock are different clocks and creates synchronizer circuits to pass signals between the clock domains.  It also creates some TIG constraints that ignore all paths between the Microblaze and AXI clocks.  In my case, those clocks are actually the same clock, which means that all paths in the clock domain get ignored.  A quick solution was to comment out the offending TIG constrains as Jared suggested.  The permanent solution is to modify the configuration of the interrupt controller in XPS.  There are two relevant configuration options: Connect Microblaze Clock and Enable/Disable Synchronizers.  Disabling either one will prevent the core from generating the offending TIG constraints.  I disabled both since I know that the clocks are the same in my design.


I do question whether the interrupt controller should be generating those constraints though.  Even if they are separate clocks, there may be paths between them that need to be constrained and having this ignore rule will override any other constraints on those paths in the design.  Maybe it would be ok if they were limited to synthesis of the interrupt controller, but since the rules get pulled into the overall design it can cause problems.

0 Kudos