Hello all, I am working on a design for a Xilinx V2P50 and I am trying to diagnose possible timing issues because the hardware performance of my design does not appear to match simulation. I have run the design through Timing Analyzer (ISE 8.2) and notice a huge number of unconstrained paths of the following format "FROM *clk_pad* TO *register*" where *clk_pad* is a clock pad in the design, and *register* is a register in the design that is clocked. Am I missing a necessary timing constraint to eliminate these unconstrained paths? I have period constraints for all of the clocks in the design. If these paths are "correctly" unconstrained, is there any way to eliminate them from Timing Analyzer easily (preferably via command line, not in the GUI) so that only valuable unconstrained paths appear? Thanks for all of your help.
Xilinx timing constraints incorrect?
Started by ●October 15, 2007
Reply by ●October 15, 20072007-10-15
paragon.john@gmail.com wrote:> If these > paths are "correctly" unconstrained, is there any way to eliminate > them from Timing Analyzer easily (preferably via command line, not in > the GUI) so that only valuable unconstrained paths appear?I'm sure there is, but I don't have a quick answer to that question. I can tell you what I would do. 1. Reduce the number of clocks to a minimum. 2. Synthesize a separate module for each clock and work out Fmax for each domain. 3. Instance the modules with known-good synchronization as needed. -- Mike Treseler
Reply by ●October 15, 20072007-10-15
paragon.john@gmail.com wrote:> Hello all, > > I am working on a design for a Xilinx V2P50 and I am trying to > diagnose possible timing issues because the hardware performance of my > design does not appear to match simulation. > > I have run the design through Timing Analyzer (ISE 8.2) and notice a > huge number of unconstrained paths of the following format > > "FROM *clk_pad* TO *register*" > > where *clk_pad* is a clock pad in the design, and *register* is a > register in the design that is clocked... >I think those only occur when a local net is used somewhere in the clock path. Are you using a gated clock? Is the clock pad using a pin other than the one with a direct connection to a global clock buffer? Why don't you post one of the unconstrained paths. That is, the part that should look something like: ================================================================================ Timing constraint: Unconstrained path analysis 868 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold errors) Maximum delay is 6.513ns. -------------------------------------------------------------------------------- Delay: 3.654ns (data path) Source: GIGE_CLK_N (PAD) Destination: aurora_rt2_e/PROTOCOL_ENG1/lane_0_mgt_i (HSIO) Data Path Delay: 3.654ns (Levels of Logic = 3) Data Path: GIGE_CLK_N to aurora_rt2_e/PROTOCOL_ENG1/lane_0_mgt_i Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- B15.PADOUT Tiopp 0.312 GIGE_CLK_N GIGE_CLK_N C15.DIFFI_IN net (fanout=1) 0.000 TOP_MGT_CLK_BUF/SLAVEBUF.DIFFIN C15.I Tdiffin 0.843 GIGE_CLK_P TOP_MGT_CLK_BUF/IBUFDS BUFGMUX3P.I0 net (fanout=3) 0.435 TOP_REF_CLK2 BUFGMUX3P.O Tgi0o 0.057 TOP_USER_CLK_BUF TOP_USER_CLK_BUF GT_X3Y1.RXUSRCLK net (fanout=527) 2.007 TOP_USER_CLK ------------------------------------------------- --------------------------- Total 3.654ns (1.212ns logic, 2.442ns route) (33.2% logic, 66.8% route)
Reply by ●October 16, 20072007-10-16
On Oct 15, 7:31 pm, Duane Clark <junkm...@junkmail.com> wrote:> paragon.j...@gmail.com wrote: > > Hello all, > > > I am working on a design for a Xilinx V2P50 and I am trying to > > diagnose possible timing issues because the hardware performance of my > > design does not appear to match simulation. > > > I have run the design through Timing Analyzer (ISE 8.2) and notice a > > huge number of unconstrained paths of the following format > > > "FROM *clk_pad* TO *register*" > > > where *clk_pad* is a clock pad in the design, and *register* is a > > register in the design that is clocked... > > I think those only occur when a local net is used somewhere in the clock > path. Are you using a gated clock? Is the clock pad using a pin other > than the one with a direct connection to a global clock buffer? > > Why don't you post one of the unconstrained paths. That is, the part > that should look something like: > > [removed for readability]Thanks for your response. I do have a gated clock of the following form: GATED_CLOCK <= ENABLE and not GATED_CLOCK. This signal is not used to clock any flip flops in the FPGA, it is immediately connected to an output buffer. Unfortunately, this signal is needed. Maybe there are some constraints I need to put on this signal that I am unaware of? Here is an example unconstrained path: -------------------------------------------------------------------------------- Delay: 1.435ns (data path) Source: Clk_n (PAD) Destination: [Flip-flop in hierarchy] (FF) Data Path Delay: 1.435ns (Levels of Logic = 4) Constraint Improvement Wizard Data Path: Clk_n to [Flip-flop in hierarchy] Delay type Delay(ns) Logical Resource(s) ---------------------------- ------------------- Tiopp 0.276 Clk_n net (fanout=1) 0.000 U_AD_IF/IBUFG_Clk/SLAVEBUF.DIFFIN Tdiffin 0.812 U_AD_IF/IBUFG_Clk/IBUFDS net (fanout=1) 0.452 U_AD_IF/BUF_Clk Tdcmino -2.529 U_AD_IF/DCM_Clk net (fanout=1) 0.823 U_AD_IF/DCM_Clk_0 Tgi0o 0.050 U_AD_IF/BUFG_Clk net (fanout=20886) 1.551 AD_Clk ---------------------------- --------------------------- Total 1.435ns (-1.391ns logic, 2.826ns route) Thanks!
Reply by ●October 16, 20072007-10-16
On Oct 16, 9:36 am, paragon.j...@gmail.com wrote:> On Oct 15, 7:31 pm, Duane Clark <junkm...@junkmail.com> wrote: > > > > > paragon.j...@gmail.com wrote: > > > Hello all, > > > > I am working on a design for a Xilinx V2P50 and I am trying to > > > diagnose possible timing issues because the hardware performance of my > > > design does not appear to match simulation. > > > > I have run the design through Timing Analyzer (ISE 8.2) and notice a > > > huge number of unconstrained paths of the following format > > > > "FROM *clk_pad* TO *register*" > > > > where *clk_pad* is a clock pad in the design, and *register* is a > > > register in the design that is clocked... > > > I think those only occur when a local net is used somewhere in the clock > > path. Are you using a gated clock? Is the clock pad using a pin other > > than the one with a direct connection to a global clock buffer? > > > Why don't you post one of the unconstrained paths. That is, the part > > that should look something like: > > > [removed for readability] > > Thanks for your response. > > I do have a gated clock of the following form: GATED_CLOCK <= ENABLE > and not CLOCK. This signal is not used to clock any flip flops > in the FPGA, it is immediately connected to an output buffer. > Unfortunately, this signal is needed. Maybe there are some > constraints I need to put on this signal that I am unaware of? > > Here is an example unconstrained path: > > -------------------------------------------------------------------------------- > Delay: 1.435ns (data path) > Source: Clk_n (PAD) > Destination: [Flip-flop in hierarchy] (FF) > Data Path Delay: 1.435ns (Levels of Logic = 4) > Constraint Improvement Wizard > Data Path: Clk_n to [Flip-flop in hierarchy] > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tiopp 0.276 Clk_n > net (fanout=1) 0.000 U_AD_IF/IBUFG_Clk/SLAVEBUF.DIFFIN > Tdiffin 0.812 U_AD_IF/IBUFG_Clk/IBUFDS > net (fanout=1) 0.452 U_AD_IF/BUF_Clk > Tdcmino -2.529 U_AD_IF/DCM_Clk > net (fanout=1) 0.823 U_AD_IF/DCM_Clk_0 > Tgi0o 0.050 U_AD_IF/BUFG_Clk > net (fanout=20886) 1.551 AD_Clk > ---------------------------- --------------------------- > Total 1.435ns (-1.391ns logic, 2.826ns route) > > Thanks!Correction to the above post: The gated clock should be GATED_CLOCK <= ENABLE and not CLOCK Note that this clock is a divided by 4 clock of the clock in the above constraint, generated by the DCM.
Reply by ●October 16, 20072007-10-16
paragon.john@gmail.com wrote:> > I do have a gated clock of the following form: GATED_CLOCK <= ENABLE > and not GATED_CLOCK. This signal is not used to clock any flip flops > in the FPGA, it is immediately connected to an output buffer.As long as it is not used internally, I wouldn't worry about it.> > Here is an example unconstrained path: > > -------------------------------------------------------------------------------- > Delay: 1.435ns (data path) > Source: Clk_n (PAD) > Destination: [Flip-flop in hierarchy] (FF) > Data Path Delay: 1.435ns (Levels of Logic = 4) > Constraint Improvement Wizard > Data Path: Clk_n to [Flip-flop in hierarchy] > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tiopp 0.276 Clk_n > net (fanout=1) 0.000 U_AD_IF/IBUFG_Clk/SLAVEBUF.DIFFIN > Tdiffin 0.812 U_AD_IF/IBUFG_Clk/IBUFDS > net (fanout=1) 0.452 U_AD_IF/BUF_Clk > Tdcmino -2.529 U_AD_IF/DCM_Clk > net (fanout=1) 0.823 U_AD_IF/DCM_Clk_0 > Tgi0o 0.050 U_AD_IF/BUFG_Clk > net (fanout=20886) 1.551 AD_Clk > ---------------------------- --------------------------- > Total 1.435ns (-1.391ns logic, 2.826ns route) >I guess it reports paths that go through the DCM, perhaps because a local net is used. It doesn't look to me like it matters, and that should not be affecting the design operation. Your problem is almost certainly elsewhere. Is your period constraint on the input signal, clk_n? I recognize that if these paths are uninteresting, you want to eliminate them from the report to see if there are any interesting paths left (I doubt you will find your problem that way, but it might help). I suppose you could eliminate the unconstrained paths with a FROM/TO constraint. You could perhaps do a global TIMESPEC "TSPADS2CLK" = FROM "PADS" TO "FFS" 2 ns; Or perhaps try to make it a bit more restricted, though I would have to experiment a bit to find the correct syntax. Perhaps something like: NET "CLK_n" TNM_NET = "CLK_N"; TIMESPEC "TSPADS2CLK" = FROM "CLK_N" TO "FFS" 2 ns;
Reply by ●October 16, 20072007-10-16
On Oct 16, 11:52 am, Duane Clark <junkm...@junkmail.com> wrote:> paragon.j...@gmail.com wrote: > > > I do have a gated clock of the following form: GATED_CLOCK <= ENABLE > > and not GATED_CLOCK. This signal is not used to clock any flip flops > > in the FPGA, it is immediately connected to an output buffer. > > As long as it is not used internally, I wouldn't worry about it. > > > > > > > Here is an example unconstrained path: > > > -------------------------------------------------------------------------------- > > Delay: 1.435ns (data path) > > Source: Clk_n (PAD) > > Destination: [Flip-flop in hierarchy] (FF) > > Data Path Delay: 1.435ns (Levels of Logic = 4) > > Constraint Improvement Wizard > > Data Path: Clk_n to [Flip-flop in hierarchy] > > Delay type Delay(ns) Logical Resource(s) > > ---------------------------- ------------------- > > Tiopp 0.276 Clk_n > > net (fanout=1) 0.000 U_AD_IF/IBUFG_Clk/SLAVEBUF.DIFFIN > > Tdiffin 0.812 U_AD_IF/IBUFG_Clk/IBUFDS > > net (fanout=1) 0.452 U_AD_IF/BUF_Clk > > Tdcmino -2.529 U_AD_IF/DCM_Clk > > net (fanout=1) 0.823 U_AD_IF/DCM_Clk_0 > > Tgi0o 0.050 U_AD_IF/BUFG_Clk > > net (fanout=20886) 1.551 AD_Clk > > ---------------------------- --------------------------- > > Total 1.435ns (-1.391ns logic, 2.826ns route) > > I guess it reports paths that go through the DCM, perhaps because a > local net is used. It doesn't look to me like it matters, and that > should not be affecting the design operation. Your problem is almost > certainly elsewhere. Is your period constraint on the input signal, clk_n? > > I recognize that if these paths are uninteresting, you want to eliminate > them from the report to see if there are any interesting paths left (I > doubt you will find your problem that way, but it might help). I suppose > you could eliminate the unconstrained paths with a FROM/TO constraint. > You could perhaps do a global > TIMESPEC "TSPADS2CLK" = FROM "PADS" TO "FFS" 2 ns; > Or perhaps try to make it a bit more restricted, though I would have to > experiment a bit to find the correct syntax. Perhaps something like: > NET "CLK_n" TNM_NET = "CLK_N"; > TIMESPEC "TSPADS2CLK" = FROM "CLK_N" TO "FFS" 2 ns;The period constraint is on clk_n's differential counterpart clk_p. Similar unconstrained paths appear for clk_p, I just happened to pick one that used clk_n. I will try a FROM/TO constraint to remove them. Since you doubt that going down this path will help me out, do you have any insight on what may be a better way to diagnose possible timing issues that may result in a mismatch? I have looked through the warnings that the various stages of ISE spit and haven't seen any that would lend themselves to a simulation mismatch. Thanks.
Reply by ●October 16, 20072007-10-16
paragon.john@gmail.com wrote:> I will try a FROM/TO constraint to remove them. Since you doubt that > going down this path will help me out, do you have any insight on what > may be a better way to diagnose possible timing issues that may result > in a mismatch?The answer is usually a missing handshake, synchronizer, transition detector, clock enable or fifo. These problems are hard to see at ground level. It is easier for me to guarantee synchronization from the top down than it is to decode cryptic timing warnings after the fact. This is the only way I know of to make good use of simulation. -- Mike Treseler
Reply by ●October 16, 20072007-10-16
paragon.john@gmail.com wrote:> > The period constraint is on clk_n's differential counterpart clk_p. > Similar unconstrained paths appear for clk_p, I just happened to pick > one that used clk_n. > > I will try a FROM/TO constraint to remove them. Since you doubt that > going down this path will help me out, do you have any insight on what > may be a better way to diagnose possible timing issues that may result > in a mismatch? I have looked through the warnings that the various > stages of ISE spit and haven't seen any that would lend themselves to > a simulation mismatch.You really have not described what the circuit is like. Are there multiple clocks? Are signals crossing between clock domains? Does it actually work correctly at lower clock rates (you said that "the hardware performance of my design does not appear to match simulation"). Mike described the most common problems, and those match my experience too. For difficult problems, if you have not tried chipscope before, give it a try. It is quite handy (hopefully you have an accessible jtag port). If you don't already have it, you can get a trial license for it and start using it immediately. I will sometimes insert a simple error detection circuit in the FPGA that can generate a trigger for chipscope.
Reply by ●October 16, 20072007-10-16
On Oct 16, 4:06 pm, Duane Clark <junkm...@junkmail.com> wrote:> paragon.j...@gmail.com wrote: > > > The period constraint is on clk_n's differential counterpart clk_p. > > Similar unconstrained paths appear for clk_p, I just happened to pick > > one that used clk_n. > > > I will try a FROM/TO constraint to remove them. Since you doubt that > > going down this path will help me out, do you have any insight on what > > may be a better way to diagnose possible timing issues that may result > > in a mismatch? I have looked through the warnings that the various > > stages of ISE spit and haven't seen any that would lend themselves to > > a simulation mismatch. > > You really have not described what the circuit is like. > Are there multiple clocks? > Are signals crossing between clock domains? > Does it actually work correctly at lower clock rates (you said that "the > hardware performance of my design does not appear to match simulation"). > > Mike described the most common problems, and those match my experience > too. For difficult problems, if you have not tried chipscope before, > give it a try. It is quite handy (hopefully you have an accessible jtag > port). If you don't already have it, you can get a trial license for it > and start using it immediately. I will sometimes insert a simple error > detection circuit in the FPGA that can generate a trigger for chipscope.This a digital signal processing application done mainly in System Generator. There is one "main" clock domain where all of the critical processing is done. There are domains synchronous to this clock made using clock enables (in System Generator) and also divided clocks that are output by a DCM (in the VHDL that I wrap the sysgen design). I believe that all of this is constrained and controlled properly. There is a asynchronous second clock domain that is used purely for command and control of the design via setting and reading registers. The signals crossing this domain would not affect the performance of the design. The type of simulation mismatch I am seeing is the "performance" of the algorithm I am implementing. The algorithm works, just not as well as I see when I run simulations. I can't use ChipScope, unfortunately. I can get at some test signals via a logic analyzer, but obviously not with the flexibility and ease of chipscope.
