cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
13,648 Views
Registered: ‎12-14-2011

Timing Constraints

Hi,

 

I am very confused! I have a constraint in my ucf file:

 

NET "FPGA_CLK_P" TNM_NET = "FPGA_CLK";
NET "FPGA_CLK_N" TNM_NET = "FPGA_CLK";
TIMESPEC TS_FPGA_CLK = PERIOD "FPGA_CLK" 100 MHz HIGH 50% INPUT_JITTER 2 ps;

 

The constraint is found and reported to have been met. But when I look through the timing reports etc, it is obviously being ignored. The Timing Constraints Report shows derived constraints (following the clock signal through PLLs and buffers), but these all have 0 paths analysed when I look them up in the Timing Report.

 

The design:

----------------

Input clock is differential (FPGA_CLK_P & FPGA_CLK_N) at 100MHz.

I feed this into an IBUFGDS giving me a single ended clk and then into a CLK Wizard v3_6.

The clk wizard input source is specified as Global Buffer.

The clk wizard outputs two clocks: 100MHz and 200MHz, both with BUFG. Clock Feedback is automatic on-chip.

The Wizard uses a PLL_Base primitive. 

 

The 100MHz output clock is called Clk_Sys. It clocks pretty much the entire FPGA at 100MHz. 

 

 

Timing Report sections:

-----------------------------------

Timing constraint: TS_FPGA_CLK = PERIOD TIMEGRP "FPGA_CLK" 10 ns HIGH 50% INPUT_JITTER 0.1 ns;
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.334ns

 


Timing constraint: TS_uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkout0 = PERIOD TIMEGRP "uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkout0" TS_FPGA_CLK HIGH 50% INPUT_JITTER 0.1 ns;
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.570ns.

 

Timing constraint: TS_sys_clk_pin = PERIOD TIMEGRP "sys_clk_pin" 100 MHz 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.570ns.

 

 

And the derived constraint report shows:

 

Derived Constraint Report
Derived Constraints for TS_FPGA_CLK

Derived Constraint Report 

Derived Constraints for TS_FPGA_CLK

 +-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+

 |                               |   Period    |       Actual Period       |      Timing Errors        |      Paths Analyzed       |

 |           Constraint          | Requirement |-------------+-------------|-------------+-------------|-------------+-------------|

 |                               |             |   Direct    | Derivative  |   Direct    | Derivative  |   Direct    | Derivative  |

 +-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+

 |TS_FPGA_CLK                    |     10.000ns|      3.334ns|      6.396ns|            0|            0|            0|          168|

 | TS_uB_Wrapper_0_Clk_Selector_0|      5.000ns|      2.800ns|      3.198ns|            0|            0|            0|          168|

 | _clk_wiz_v3_6_inst_clkout1    |             |             |             |             |             |             |             |

 |  TS_MIG_Wrapper_0_MIG_lower_Wr|     10.000ns|      3.496ns|          N/A|            0|            0|          168|            0|

 |  apper_memc3_infrastructure_in|             |             |             |             |             |             |             |

 |  st_mcb_drp_clk_bufg_in       |             |             |             |             |             |             |             |

 |  TS_MIG_Wrapper_0_MIG_lower_Wr|      2.500ns|      1.599ns|          N/A|            0|            0|            0|            0|

 |  apper_memc3_infrastructure_in|             |             |             |             |             |             |             |

 |  st_clk_2x_180                |             |             |             |             |             |             |             |

 |  TS_MIG_Wrapper_0_MIG_lower_Wr|      2.500ns|      1.599ns|          N/A|            0|            0|            0|            0|

 |  apper_memc3_infrastructure_in|             |             |             |             |             |             |             |

 |  st_clk_2x_0                  |             |             |             |             |             |             |             |

 | TS_uB_Wrapper_0_Clk_Selector_0|     10.000ns|      3.570ns|          N/A|            0|            0|            0|            0|

 | _clk_wiz_v3_6_inst_clkout0    |             |             |             |             |             |             |             |

 +-------------------------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------+

 

That's not the clearest table but what it shows is that the 100MHz clock is completely ignored in the analysis. All the derived clock constraints as shown above have zero analysed paths...

 

 

The only notable thing was that intersecting Constraints were found and resolved. I suspect that has something to do with it, but I do not know what exactly?!

 

I am not sure what I am doing wrong. Anyone got any ideas?

 

Al.

 

0 Kudos
11 Replies
Highlighted
Teacher
Teacher
13,646 Views
Registered: ‎03-31-2012

remove the line which mentions the _N pin and see if it helps:

#NET "FPGA_CLK_N" TNM_NET = "FPGA_CLK";
- 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.
0 Kudos
Highlighted
Observer
Observer
13,635 Views
Registered: ‎12-14-2011

A good idea. I already gave this a go thinking it might be interpreting two individual clocks. No luck. I've also tried changing the wizard primitive. Originally the design had a startup_spartan6 primitive and a BUFGMUX. I removed those and simplified it down to the bare essentials.

Thanks again for the suggestion.
0 Kudos
Highlighted
Guide
Guide
13,629 Views
Registered: ‎01-23-2009

I don't think there is anything wrong.

 

You defined a TIMESPEC on the input clock pin FPGA_CLK_P (the one on N should be removed). It is correct that this TIMESPEC constrains no paths. This "clock" goes only to the input of the PLL, and "ends" there.

 

When this timespec propagates forward to the PLLs, the tools derive new timespecs based on the input timespec. You can see their names in the derived clock report. You can further see how they are derived by looking at the ngdbuild log file (the .bld file). Of particular note is the one named  TS_uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkout0

 

This one is clearly a TIMESPEC created by a clock module (presumably a PLL) generated by the Clock Wizard on the clkout0 output. This is your ClkSys. This constraint shows that there are paths, and that all the paths meet timing. All the other timespecs are presumably generated from other PLLs/DCMs/MMCMs in the design, all generating new TIMESPECs, and they all pass.

 

Avrum

0 Kudos
Highlighted
Teacher
Teacher
13,624 Views
Registered: ‎03-31-2012

For TS_FPGA clock and TS_uB_Wrapper_0_Clk_Selector_0 there are 168 derivative paths and for TS_MIG_Wrapper_0_MIG_lower_Wr there are 168 direct paths which are analyzed. You must have 168 registers in your design and only the final clock which is driving these registers is mentioned as direct. The other clocks arrive there as derivative. If you think you have more registers than that, show us the resource report for analysis.
- 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.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
13,621 Views
Registered: ‎05-14-2008

There may be constraints interaction in your design. That is to say, some constraints may be overridden by some other constraints so the number of paths analyzed is 0. Can you post the entire timing report?

 

Vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
13,604 Views
Registered: ‎12-14-2011

Firstly, thank you all for the expert advise.

 

I've attached the timing report and utilization. There is definitely something funny here! I have several clock domains in the design. A 'DAC' clock which I use to drive a bunch of OSERDES2s. This is a small chunk of the design and it still has 250,000 paths. This domain creates a 200MHz DDR output, and it seems to be fine.

 

The sys clock drives about 25% of the entire device, including a microblaze, a MIG block and heaps of FFs, and it is all there. I can actually run it up in hardware and it works (at ~80MHz). At 100MHz, the microblaze gets in a twist and locks up! 

 

My understanding was that the derived clock constraints would be propagated from the original 100MHZ constraint through to the other clocks it generates (multiplied up appropriately). The derived constraint relating to the 168 paths is off inside the MIG block. There just aren't any paths for the sys clk.

 

I'm doing something quite stupid. But I just can't see it for staring too long at it! I think VivianY is right that there is a constraint interaction. Any ideas how to flush this out? I've asked the 'implement  design properties' to output a constraints interaction report, but it isn't created. 

 

I am going to read austin's constraints guide for dumbos now.

 

Al.

0 Kudos
Highlighted
Observer
Observer
13,602 Views
Registered: ‎12-14-2011

Thanks to Austin for the Constraints Guide. First page had some comments that explained how to get the the tsi report out. In this report I read the the following:

 

Constraint Interaction Report
=============================

Constraint interactions for PATH "TS_AXI_MB_FP_axi_intc_0_path" TIG;
301959 paths removed by PATH "TS_ICAP_SYS_FP_axi_hwicap_0_path" TIG;
203442 paths removed by PATH "TS_SYS_ICAP_FP_axi_hwicap_0_path" TIG;
2 paths removed by PATH "TS_TIG_microblaze_0_Reset_path" TIG;
1 paths removed by PATH "TS_TIG_microblaze_0_dlmb_POR_FF_I_path" TIG;
1 paths removed by PATH "TS_TIG_microblaze_0_ilmb_POR_FF_I_path" TIG;

Consolidating the following similar constraints may reduce the memory and runtime required for timing analysis:
PATH "TS_ICAP_SYS_FP_axi_hwicap_0_path" TIG;
PATH "TS_SYS_ICAP_FP_axi_hwicap_0_path" TIG;
PATH "TS_TIG_microblaze_0_Reset_path" TIG;
PATH "TS_TIG_microblaze_0_dlmb_POR_FF_I_path" TIG;
PATH "TS_TIG_microblaze_0_ilmb_POR_FF_I_path" TIG;

Constraint interactions for PATH "TS_ICAP_SYS_FP_axi_hwicap_0_path" TIG;
259474 paths removed by PATH "TS_SYS_ICAP_FP_axi_hwicap_0_path" TIG;

Constraint interactions for PATH "TS_MB_AXI_FP_axi_intc_0_path" TIG;
2885790 paths removed by PATH "TS_AXI_MB_FP_axi_intc_0_path" TIG;

Constraint interactions for PATH "TS_axi4lite_0_reset_resync_path" TIG;
5 paths removed by PATH "TS_MB_AXI_FP_axi_intc_0_path" TIG;

Constraint interactions for TS_MIG_Wrapper_0_MIG_lower_Wrapper_memc3_infrastructure_inst_mcb_drp_clk_bufg_in = PERIOD TIMEGRP "MIG_Wrapper_0_MIG_lower_Wrapper_memc3_infrastructure_inst_mcb_drp_clk_bufg_in" TS_uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clk2x * 0.5 HIGH 50% INPUT_JITTER 0.002 ns;
17 paths removed by PATH "TS_SYS_ICAP_FP_axi_hwicap_0_path" TIG;

Constraint interactions for TS_sys_clk_pin = PERIOD TIMEGRP "sys_clk_pin" 100 MHz HIGH 50%;
252 paths removed by TS_uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkfx = PERIOD TIMEGRP "uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkfx" TS_FPGA_CLK HIGH 50% INPUT_JITTER 0.002 ns;

Constraint interactions for TS_uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkfx = PERIOD TIMEGRP "uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkfx" TS_FPGA_CLK HIGH 50% INPUT_JITTER 0.002 ns;
2380385 paths removed by PATH "TS_AXI_MB_FP_axi_intc_0_path" TIG;
42485 paths removed by PATH "TS_ICAP_SYS_FP_axi_hwicap_0_path" TIG;
462916 paths removed by PATH "TS_SYS_ICAP_FP_axi_hwicap_0_path" TIG;
2 paths removed by PATH "TS_TIG_microblaze_0_Reset_path" TIG;
1 paths removed by PATH "TS_TIG_microblaze_0_dlmb_POR_FF_I_path" TIG;
1 paths removed by PATH "TS_TIG_microblaze_0_ilmb_POR_FF_I_path" TIG;

Consolidating the following similar constraints may reduce the memory and runtime required for timing analysis:
PATH "TS_AXI_MB_FP_axi_intc_0_path" TIG;
PATH "TS_ICAP_SYS_FP_axi_hwicap_0_path" TIG;
PATH "TS_SYS_ICAP_FP_axi_hwicap_0_path" TIG;
PATH "TS_TIG_microblaze_0_Reset_path" TIG;
PATH "TS_TIG_microblaze_0_dlmb_POR_FF_I_path" TIG;
PATH "TS_TIG_microblaze_0_ilmb_POR_FF_I_path" TIG;


Clock Domain Overlap Report
===========================

TS_sys_clk_pin = PERIOD TIMEGRP "sys_clk_pin" 100 MHz HIGH 50%;
TS_uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkfx = PERIOD TIMEGRP "uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkfx" TS_FPGA_CLK HIGH 50% INPUT_JITTER 0.002 ns;
{
uB_Wrapper_0/EDK_V1_1_top_0/EDK_V1_1_i/microblaze_0_bram_block/microblaze_0_bram_block/ramb16bwer_10 (uB_Wrapper_0/EDK_V1_1_top_0/EDK_V1_1_i/microblaze_0_bram_block/microblaze_0_bram_block/ramb16bwer_10.CLKA)
uB_Wrapper_0/EDK_V1_1_top_0/EDK_V1_1_i/microblaze_0_bram_block/microblaze_0_bram_block/ramb16bwer_10 (uB_Wrapper_0/EDK_V1_1_top_0/EDK_V1_1_i/microblaze_0_bram_block/microblaze_0_bram_block/ramb16bwer_10.CLKB)

...

...

...

 

 

}

 

Does this mean that the two derived constraints (in red and green above) are overlapping. Note: these are both derived from the same original source constaint I wrote into the UCF, so that would be nuts! 

 

Or are the TIG constraints doing something nasty (in purple above)? Those are not in the UCF. I think they are coming from inside the Microblaze source code, as in the stuff that EDK generates. 

 

Thanks all,

 

Al.

 

 

 

 

0 Kudos
Highlighted
Observer
Observer
13,598 Views
Registered: ‎12-14-2011

One more contribution. I searched the web for this problem and someone in Germany has encountered it. He solved it by changing C_MB_CLK_NOT_CONNECTED = 1 in the intc block inside XPS. Unfortunately, in my design I am using a fast interrupt. In the intc pdf, it states: 

 

"G15 C_HAS_FAST G14 - C_MB_CLK_NOT_CONNECTED has to be 0 when C_HAS_FAST is"

 

So this looks like a right old mess caused by the microblaze. Either I go back to only using standard interrupts... But I can't see how to change this parameter in the MPD file. It's read only, and hte option isn't present on the configure IP dialog.

 

Al.

 

0 Kudos
Highlighted
Guide
Guide
13,594 Views
Registered: ‎01-23-2009

First, I think you left out part of the TSI report - specifically, I would look for information that it may have on the TS_OSERDES_gen_OSERDES_Wrapper_clkgen_pllout_x1 timespec...

 

Clearly there is something mismatched between your expectation and what the tools are interpreting. For us to help you would need to send us more information - specifically the complete UCF file, and, ideally, a drawing or schematic that shows the clocks in your system (the clock inputs, MMCMs, PLLs, and clock buffers used).

 

Likely one of the groups you are defining is too vague and is picking up tons of endpoints that aren't supposed to be in the group. This could be done by (as an example) using

 

NET "name_of_object" TNM = group_name;

 

when you meant

 

INST "name_of_object" TNM = group_name;

 

If the name_of_object is a flip-flop, then the first one puts the actual flip-flop in the group, but the second one puts all flip-flops that can be combinatorially reached from the output of the first flip-flop in the group.

 

Avrum

0 Kudos
Highlighted
Observer
Observer
9,560 Views
Registered: ‎12-14-2011

Update with progress...

 

It is the intc block. What's happened is this:

 

The intc block has two clock inputs, AXI_ACLK & processor_clk. These are used in the AXI_LITE_IPIF and the intc core respectively. Now, in the MPD file for the intc, you will see the cryptic C_MB_CLK_NOT_CONNECTED parameter is set to 0. This is a generic input to the intc VHDL block. I interpret it to mean that XST etc will treat the two clocks listed above as separate clocks. In my case it creates a TIG constraint across the path from one domain to the other. Unfortunately, since they are actually the same domain, it basically ignores all constraints on this domain (of particular interest here: the PERIOD). Since it's a TIG, it trumps all other constraints (TIG has highest priority of all timing constraints). Bummer! If you could set C_MB_CLK_NOT_CONNECTED = 1, that would instruct XST that the clock domains are actually the same. Unfortunately, there is no neat way to achieve this since the MPD file for the intc is read only.

 

So, my solution, which is still at a half baked stage, is to edit the VHDL source and replace the generic with a constant (C_MB_CLK_NOT_CONNECTED = 1). This is then fed down through the rest of the VHDL source files as a generic. The datasheet for the intc states that you must not set USE_FAST = 1 if you are selecting this clock set up (exactly how you were supposed to change the read only parameter, I'm still not sure. I'm positive Xilinx aren't encouraging us to chop up the source code like this). So in addition, I'll have to rewrite my microblaze application to NOT use the fast interrupts. Fortunately, I had such a hard time getting them to work in the first place, that I left a define in the code to switch between using normal and fast. So it's only one line of code. 

 

Having done this and rerun the implementation, I now FAIL timing. Hurray!

 

Timing constraint: TS_uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkfx = PERIOD TIMEGRP
"uB_Wrapper_0_Clk_Selector_0_clk_wiz_v3_6_inst_clkfx" TS_FPGA_CLK HIGH
50% INPUT_JITTER 0.002 ns;

For more information, see Period Analysis in the Timing Closure User Guide (UG612).
2380285 paths analyzed, 47098 endpoints analyzed, 54 failing endpoints
54 timing errors detected. (54 setup errors, 0 hold errors, 0 component switching limit errors)
Minimum period is 10.624ns.

 

This is good news. That's over 2 million paths it didn't see before. However, I suspect it's not the only place this has happened. Having done this, I now notice that:

 


Timing constraint: PATH "TS_ICAP_SYS_FP_axi_hwicap_0_path" TIG;
42485 paths analyzed, 2133 endpoints analyzed, 0 failing endpoints
0 timing errors detected. (0 setup errors, 0 hold errors)

 

and 

 

Timing constraint: PATH "TS_SYS_ICAP_FP_axi_hwicap_0_path" TIG;
462993 paths analyzed, 19200 endpoints analyzed, 0 failing endpoints
0 timing errors detected. (0 setup errors, 0 hold errors)

 

which are similar looking TIG constraints. I wonder whether it's intentional to constrain those over half a million paths. So I hunt around inside the TSI report and find that these relate to the paths from ICAP_Clk to S_AXI_ACLK and vice versa. So, going back to my project in ISE, I can see that this is a real path in both directions, but ICAP_Clk is actually left floating in the design! This seems a bit odd, since this should all get optimized out!? Why are there 500,000 paths? I delete the ICAP since I'm not using it. Problem solved. After all that, I still don't meet timing because the Microblaze can't go at 100MHz. So, I reconfigure the microblaze itself to remove the barrel shifter and the FPU which I'm not planning on using. Also I reduce the size of the BRAM to 32K from 64K. And at last, I meet timing! 

 

This has been a MASSIVE red herring. I've been seeing odd behaviour in my microblaze for months now, but my timing was apparantly fine. So, I've been debugging my C code for weeks, and hanging a scope off my clock generation chip. What a monumental waste of time this has been. I'm not a fan of the microblaze. It does stuff like this. Deep hidden buttons that you can't reach to push, even if you knew where they were or what they do.

 

Xilinx, would you be able to give me a pointer on how to work around this issue more cleanly. Ideally, I'd like to use my fast interrupts again. Also, crashing around inside your delicately written source code is making me very uncorfortable!

 

Thanks to contributors. I think in the end, this was too convoluted a problem to solve without access to the full project.

 

Al.

 

 

 

 

 

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,502 Views
Registered: ‎08-06-2007

Hi,

 

Sorry for a long delay answering this, I never saw this post until today.

 

There is no need to modify the source code.

You only need to add this in the .mhs file for the AXI_INTC.

PARAMETER C_DISABLE_SYNCHRONIZERS = 1

 

This will disable the synchronizers and also the TIG constraint (since there is no asynchronous clock domain crossing).

As I understand it  the EDK tool normally should automatically detect that the processor_clk and axi_aclk is the same and then set this parameter to '1'.

Could you provide the .mhs so I can see why EDK fails to detect this?

 

The parameter C_MB_CLK_NOT_CONNECTED should be 0 so you can still use fast interrupts.

 

Göran