08-21-2014 10:43 AM
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:
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)
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:
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 for TS_sys_clk_pin|
TS_micro_i_clock_generator_0_clock_generator_0_SIG_PLL0_CLKOUT2 = PERIOD
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.|
|Slack: 6.876ns (period - min period limit)|
|Min period limit:||3.124ns (320.102MHz) (Trper_CLKA(Fmax))|
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.
08-26-2014 07:10 AM
09-01-2014 03:12 AM
You mentioned "The timegrp
micro_i_clock_generator_0_clock_generator_0_SIG_PL 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?
09-01-2014 03:24 AM
What are the BEL types in the timegrp
10-06-2014 06:42 AM
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.
10-10-2014 06:29 AM
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.