1. Home
  2. Field-Programmable Gate Arrays
  3. ISE Timing Analysis Misreporting? Bug?

ISE Timing Analysis Misreporting? Bug?

Ok, so I'm working with a COTs DSP board vendor's ISE project and customizing the logic (essentially tossing code in a user wrapper). Unfortunately, I'm having some 'user-friendly' issues with the project file and customizability.

Here is a snippet of what I sent to their engineer:

---------------------------------------------------------------------- Constraint | Requested | Actual | |

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

  • TS_clk_fx = PERIOD TIMEGRP "clk_fx" TS_sy | 0.000ns | -0.821ns

s_clk_in * 1.33333 HIGH 50% HOLD ERROR | |

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

  • TS_clk_fx = PERIOD TIMEGRP "clk_fx" TS_sy | 6.696ns | 20161.65ns

s_clk_in * 1.33333 HIGH 50% | |

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

  • TS_sys_clk_in = PERIOD TIMEGRP "sys_clk_i | 8.928ns | 20.255ns n" 112 MHz HIGH 50% | |

This is the PAR result from the baseline project I got off the web. I assume this project is built to operate with the 250 MHz A/Ds. Here are my assumptions:

1) The 'sys_clk_in' is over-constrained to 112 MHz (100 MHz actual) 2) The 'clk_fx' derived from the fx port of the DCM is constrained to 1.333*sys_clk_in (125 MHz = 250 MHz/2 actual)

-Notes:

1) 'sys_clk_in' is a board clock at 100 MHz (constrained to 112 MHz) 2) 'sys_clk' is derived from 'sys_clk_in' via DCM's fx output at 4/3. 'sys_clk' needs to operate at 125 MHz (constrained to ~150 MHz).

-His response: "You're right. The Xilinx tool has a bug. Something about spinning up a clock using a DCM & subsequent timing analysis. The hardware does work."

-My questions to those experienced: I've seen clock's overconstrained before with another vendor.

1) Is this a common practice? If so, I could envision timing results being highly overconstrained when dealing with DCMs.

2) Is this really a bug or is the project misconstrained?

3) Am I crazy to think it's unreasonable to be given a 'user-defineable' project with timing that is seemingly failing by default? (i.e. how am I to modify the project and know it will work if the baseline does not meet timing?)

Thanks,

-Brandon

Reply to
Brandon Jasionowski
Loading thread data ...

It is reasonably common to see designs overconstrained in the synthesis phase, to compensate for the fact that many synthesis tools underestimate the routing delays in a design. It's not an ideal situation, but often it's the only way to ensure the design meets timing later on.

The only reason I can think of to overconstrain a design at the PAR stage is if there is a requirement that the FPGA clock be variable without altering the FPGA bitstream. That is, in your case, if the sys_clk_in could theoretically one day be run at up to 112MHz.

Otherwise, overconstraining the clock at PAR is pointless (you just increase the runtime of the tools without buying yourself any extra performance).

Hard to say, without seeing the constraints file.

The "hold error" is a little worrying (maybe this is an IO placement issue?), and the 20us cycle time figure for the 150MHz "TS_clk_fx" domain is very strange indeed - is there really a path that long in the design? That sounds like a good candidate for a bug. It's not one I've heard of though (anyone?).

BTW, what version of the Xilinx tools are you using?

No, you're not crazy.

I've seen some FPGA projects where the engineer just eyeballs the log file full of timing errors and says, "that's not a problem, that's not a problem...". Not a good way to work. If you don't have any documentation of exactly why these timing errors are there and a good engineering justification of why they don't matter - preferably including timing diagrams - I would run away. If you have that option, of course. :-)

-Ben-

Reply to
Ben Jones

Ben,

Here's the timing analyzer report for one of the failing paths. I don't see where it's coming up with a period of 20.255ns. If you are curious I could paste the constraints file, but it seems fairly vanilla to me...

================================================================================ Timing constraint: TS_sys_clk_in = PERIOD TIMEGRP "sys_clk_in" 112 MHz HIGH 50%;

1270 items analyzed, 11 timing errors detected. (11 setup errors, 0 hold errors) Minimum period is 20.255ns.

-------------------------------------------------------------------------------- Slack: -2.644ns (requirement - (data path - clock path skew + uncertainty)) Source: inst_ddr/U3/BU510 (FF) Destination: inst_ddr/U3/BU212 (FF) Requirement: 2.084ns Data Path Delay: 3.140ns (Levels of Logic = 6) Clock Path Skew: -1.588ns Source Clock: sys_clk rising at 59471.130ns Destination Clock: out_clk rising at 59473.214ns Clock Uncertainty: 0.000ns Timing Improvement Wizard Data Path: inst_ddr/U3/BU510 to inst_ddr/U3/BU212 Delay type Delay(ns) Logical Resource(s) ---------------------------- ------------------- Tcko 0.419 inst_ddr/U3/BU510 net (fanout=4) 0.782 inst_ddr/U3/N6047 Topcyg 0.722 inst_ddr/U3/BU183 inst_ddr/U3/BU184 net (fanout=1) 0.000 inst_ddr/U3/N7188 Tbyp 0.088 inst_ddr/U3/BU187 inst_ddr/U3/BU190 net (fanout=1) 0.000 inst_ddr/U3/N7186 Tbyp 0.088 inst_ddr/U3/BU193 inst_ddr/U3/BU196 net (fanout=1) 0.000 inst_ddr/U3/N7184 Tbyp 0.088 inst_ddr/U3/BU199 inst_ddr/U3/BU202 net (fanout=1) 0.000 inst_ddr/U3/N7182 Tbyp 0.088 inst_ddr/U3/BU205 inst_ddr/U3/BU208 net (fanout=1) 0.000 inst_ddr/U3/BU208/O Tcinx 0.865 inst_ddr/U3/BU211 net (fanout=1) 0.000 inst_ddr/U3/N7192 Tdxck 0.000 inst_ddr/U3/BU212 ---------------------------- --------------------------- Total 3.140ns (2.358ns logic, 0.782ns route) (75.1% logic, 24.9% route)

-------------------------------------------------------------------------------- Slack: -2.580ns (requirement - (data path - clock path skew + uncertainty)) Source: inst_ddr/U3/BU503 (FF) Destination: inst_ddr/U3/BU212 (FF) Requirement: 2.084ns Data Path Delay: 3.076ns (Levels of Logic = 6) Clock Path Skew: -1.588ns Source Clock: sys_clk rising at 59471.130ns Destination Clock: out_clk rising at 59473.214ns Clock Uncertainty: 0.000ns Timing Improvement Wizard Data Path: inst_ddr/U3/BU503 to inst_ddr/U3/BU212 Delay type Delay(ns) Logical Resource(s) ---------------------------- ------------------- Tcko 0.419 inst_ddr/U3/BU503 net (fanout=4) 0.608 inst_ddr/U3/N6048 Topcyf 0.832 inst_ddr/U3/BU180 inst_ddr/U3/BU181 inst_ddr/U3/BU184 net (fanout=1) 0.000 inst_ddr/U3/N7188 Tbyp 0.088 inst_ddr/U3/BU187 inst_ddr/U3/BU190 net (fanout=1) 0.000 inst_ddr/U3/N7186 Tbyp 0.088 inst_ddr/U3/BU193 inst_ddr/U3/BU196 net (fanout=1) 0.000 inst_ddr/U3/N7184 Tbyp 0.088 inst_ddr/U3/BU199 inst_ddr/U3/BU202 net (fanout=1) 0.000 inst_ddr/U3/N7182 Tbyp 0.088 inst_ddr/U3/BU205 inst_ddr/U3/BU208 net (fanout=1) 0.000 inst_ddr/U3/BU208/O Tcinx 0.865 inst_ddr/U3/BU211 net (fanout=1) 0.000 inst_ddr/U3/N7192 Tdxck 0.000 inst_ddr/U3/BU212 ---------------------------- --------------------------- Total 3.076ns (2.468ns logic, 0.608ns route) (80.2% logic, 19.8% route)

-------------------------------------------------------------------------------- Slack: -2.550ns (requirement - (data path - clock path skew + uncertainty)) Source: inst_ddr/U3/BU188 (FF) Destination: inst_ddr/U3/BU212 (FF) Requirement: 2.084ns Data Path Delay: 3.046ns (Levels of Logic = 5) Clock Path Skew: -1.588ns Source Clock: sys_clk rising at 59471.130ns Destination Clock: out_clk rising at 59473.214ns Clock Uncertainty: 0.000ns Timing Improvement Wizard Data Path: inst_ddr/U3/BU188 to inst_ddr/U3/BU212 Delay type Delay(ns) Logical Resource(s) ---------------------------- ------------------- Tcko 0.419 inst_ddr/U3/BU188 net (fanout=1) 0.776 inst_ddr/U3/N6065 Topcyg 0.722 inst_ddr/U3/BU189 inst_ddr/U3/BU190 net (fanout=1) 0.000 inst_ddr/U3/N7186 Tbyp 0.088 inst_ddr/U3/BU193 inst_ddr/U3/BU196 net (fanout=1) 0.000 inst_ddr/U3/N7184 Tbyp 0.088 inst_ddr/U3/BU199 inst_ddr/U3/BU202 net (fanout=1) 0.000 inst_ddr/U3/N7182 Tbyp 0.088 inst_ddr/U3/BU205 inst_ddr/U3/BU208 net (fanout=1) 0.000 inst_ddr/U3/BU208/O Tcinx 0.865 inst_ddr/U3/BU211 net (fanout=1) 0.000 inst_ddr/U3/N7192 Tdxck 0.000 inst_ddr/U3/BU212 ---------------------------- --------------------------- Total 3.046ns (2.270ns logic, 0.776ns route) (74.5% logic, 25.5% route)

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

When I use the Timing Improvement Wizard hyperlink for each it says:

"75.10 percent is consumed by logic levels in this path. This path crosses clock domains from "sys_clk" to "out_clk"."

I suppose the clock domain dependence have something to do with this... I found that this "out_clk" is the input to one of their fifo controllers and is connected to the 100 MHz board clock... Fortunately I was able to convince one of their engineers that this needs to be fixed, especially since they advertise user customization of the FPGA! O_o

Thanks,

-Brandon

Ben Jones wrote:

Reply to
Brandon Jasionowski

Hi Brandon,

Yes, those paths you posted are all crossing clock domains. If the clocks are related, then this should be specified somewhere; if they are unrelated, and there is proper clock-domain-crossing synchronization logic in place, then they should be marked as "ignore" to the timing analyser by means of a "TIG" constraint. If they are the same, they shouldn't be different. If you see what I mean.

FWIW, the timing analyser comes up with the 20.255ns number by working backwards from the e.g. 3.140ns path it achieved for the offending logic, and asking itself "how slow do I have to run sys_clk_in in order for this timing error to go away?".

Cheers,

-Ben-

Reply to
Ben Jones

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.