f



timing and timing reports (again)

hi

ich have question about timing.
i have an edk design with microblaze (using spartan 3e 500) where i
use an ip core that i wrote myself.
when i implement the design i get the following timing output in my
console.

------------------------------------------------------------------------------------------------------
  Constraint                           |  Check  | Worst Case |  Best
Case | Timing |   Timing
                                            |             |
Slack       | Achievable | Errors |    Score
------------------------------------------------------------------------------------------------------
* TS_dcm_48mhz_dcm_48mhz_CLKFX_BUF = PERIOD | SETUP   |
-1.456ns|    57.246ns|       1|        1456
   TIMEGRP         "dcm_48mhz_dcm_48mhz_CLK | HOLD    |
1.025ns|            |       0|           0
  FX_BUF" TS_sys_clk_pin / 0.96 HIGH 50%    |         |
|            |        |
------------------------------------------------------------------------------------------------------
  TS_dcm_0_dcm_0_CLK0_BUF = PERIOD TIMEGRP  | SETUP   |
5.532ns|    14.468ns|       0|           0
  "dcm_0_dcm_0_CLK0_BUF" TS_sys_clk_pin     | HOLD    |
0.688ns|            |       0|           0
       HIGH 50%                             |         |
|            |        |
------------------------------------------------------------------------------------------------------
  TS_sys_clk_pin = PERIOD TIMEGRP "sys_clk_ | SETUP   |
17.975ns|     2.025ns|       0|           0
  pin" 20 ns HIGH 50%                       | HOLD    |
0.667ns|            |       0|           0
------------------------------------------------------------------------------------------------------


my constraints in the ucf file  for the clock net are (generated by
edk):
Net sys_clk_pin TNM_NET = sys_clk_pin;
TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 20000 ps;

clearly the dcm_48mhz_dcm_48mhz_CLKFX_BUF does not meet timing. my
question now is are there are some constraints that i can use to
achieve timing for that signal. or can i change something in the
design.
also when i look at the synthesis report files for the dcm48 and my
own ip they all get implemented far under their timing requirements.
is there a report where i can look up the
dcm_48mhz_dcm_48mhz_CLKFX_BUF signal an why i has such a bad timing?

thanks
urban

0
u_stadler
3/20/2008 5:36:57 PM
comp.arch.fpga 18587 articles. 2 followers. Post Follow

4 Replies
1129 Views

Similar Articles

[PageSpeed] 15

On Mar 20, 10:36 am, "u_stad...@yahoo.de" <u_stad...@yahoo.de> wrote:
> hi
>
> ich have question about timing.
> i have an edk design with microblaze (using spartan 3e 500) where i
> use an ip core that i wrote myself.
> when i implement the design i get the following timing output in my
> console.
>
> ------------------------------------------------------------------------------------------------------
>   Constraint                           |  Check  | Worst Case |  Best
> Case | Timing |   Timing
>                                             |             |
> Slack       | Achievable | Errors |    Score
> ------------------------------------------------------------------------------------------------------
> * TS_dcm_48mhz_dcm_48mhz_CLKFX_BUF = PERIOD | SETUP   |
> -1.456ns|    57.246ns|       1|        1456
>    TIMEGRP         "dcm_48mhz_dcm_48mhz_CLK | HOLD    |
> 1.025ns|            |       0|           0
>   FX_BUF" TS_sys_clk_pin / 0.96 HIGH 50%    |         |
> |            |        |
> ------------------------------------------------------------------------------------------------------
>   TS_dcm_0_dcm_0_CLK0_BUF = PERIOD TIMEGRP  | SETUP   |
> 5.532ns|    14.468ns|       0|           0
>   "dcm_0_dcm_0_CLK0_BUF" TS_sys_clk_pin     | HOLD    |
> 0.688ns|            |       0|           0
>        HIGH 50%                             |         |
> |            |        |
> ------------------------------------------------------------------------------------------------------
>   TS_sys_clk_pin = PERIOD TIMEGRP "sys_clk_ | SETUP   |
> 17.975ns|     2.025ns|       0|           0
>   pin" 20 ns HIGH 50%                       | HOLD    |
> 0.667ns|            |       0|           0
> ------------------------------------------------------------------------------------------------------
>
> my constraints in the ucf file  for the clock net are (generated by
> edk):
> Net sys_clk_pin TNM_NET = sys_clk_pin;
> TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 20000 ps;
>
> clearly the dcm_48mhz_dcm_48mhz_CLKFX_BUF does not meet timing. my
> question now is are there are some constraints that i can use to
> achieve timing for that signal. or can i change something in the
> design.
> also when i look at the synthesis report files for the dcm48 and my
> own ip they all get implemented far under their timing requirements.
> is there a report where i can look up the
> dcm_48mhz_dcm_48mhz_CLKFX_BUF signal an why i has such a bad timing?
>
> thanks
> urban

Run the design through Timing Analizer to find out which path(s) are
failing timing.

-P@
0
Pat
3/20/2008 6:40:38 PM
hi

thanks for the tip.
well i did that but to be honest i couldn't quit figure out what to do
with all the info. is there a manual or tutorial what all this means?
if somebody wants to have a look at my design i would appreciate it!
http://193.170.52.132/xilinx/system.ncd
http://193.170.52.132/xilinx/system.pcf

are there perhaps some examples from xilinx that teach you how to use
those tools and to debug?

thanks
urban

0
u_stadler
3/20/2008 10:02:43 PM
i forgot mention that i did a static timing analysis with the timing
analyzer.
i also looked into the manual for trace but i would rather have some
examples if there are some.
thanks
0
u_stadler
3/20/2008 10:53:45 PM
Three tools can be very useful when chasing down timing issues:

1) trace (timing) report:  generally, look to see the failing time specs; 
when you run it with useful options, you can get a feel for the critical 
path
2) delay report:  sort of a netlist, marginally readable... but used in 
conjunction with the timing report, you can see variations on delays on any 
common net, which may give a clue to location issues causing the timing 
problems.  You can also see how your clocks are routed; i.e, which BUFGs are 
used, etc.
3)  the FPGA Editor:  for small designs, you could go here quickly; however, 
for large designs, it takes a long time to load, so I avoid it as much as I 
can.  But when you have to do it, do it with the report information handy. 
It can then be used as a reference for manual floorplanning (as in, seeing 
how the tool did a lousy job, and then picking [better] fixed locations for 
a few critical points (e.g., BUFGs, FFs.)

A fourth 'tool' is the data sheet for the part.  All the timing definitions 
(tco, tpd, tsu, ...) are defined there; when you run across an unfamiliar 
one in the timing report, refer to the data sheet.  Sometimes the problem is 
as simple as forcing a register to be in, or out of, an IOB.

The results of this analysis should guide you in further decision-making:

1)  Floorplanning.
2)  Re-coding portions of the design to make the critical path(s) 
non-critical.
3)  Adding (or removing) timing constraints, such as multi-cycle constraints 
or Timing Ignore constraints.
4)  Telling the tool to work harder, because the solution is there...
5)  Recognizing that you just can't get there from here, and accepting lower 
peformance.

I try to avoid #5 by identifying critical paths early in the design process; 
I like to have some realistic expectation of success when I sign up to do 
something.

Nevertheless, there frequently arise cases where "sometimes it meets timing 
easily, sometimes it doesn't meet it at all."  I.e., after minor design 
changes, timing closure may fail miserably.   Usually, I end up asking 
myself, "How did the tool manage to do such a lousy job?"  By inspecting the 
timing report, I can see whether the problem is likely too many levels of 
logic, or just plain lousy mapping and placement, where the routing process 
just can't make meet timing.  (I have seen this happen many, many times over 
the last 10+ years.)

When I look at the [failing] timing report, I try to find answers to a few 
key questions (not necessarily in any order):

1)  Do the failures have something in common?  E.g, there might by 165,000 
nets failing timing, but the worst 20 (or 7,000, or...) are all part of the 
same bus.  The routing tool will often stop optimizing as it focuses all of 
its attention on the worst ones, making the problem seem worse than it 
really is.
2)  Are there outlandishly long routing delays between logic elements?  This 
is often indicative of poor placement, or not using preferred routing 
resources, such as between pins, BUFGs, and DCMs.
3)  In conjuction with the delay report, are the delays on a net roughly 
matched for all nodes, or are some way off base?  This kind of information 
gives a clue as to what you might see if you open the routed design with the 
FPGA Editor.
4)  Are the failures real?  I have often had control path failures because I 
had not initially used appropriate mutli-cycle constraints.  (Of course, 
sometimes I had to change the design to force them to be multi-cycle.  Give 
and take.)

As to examples, the ones that mean the most to you will be the ones for your 
design....  If you are overwhelmed with what you have at the moment, create 
a tiny design, over-constraint it (say, 2 GHz?), and try to make sense of 
the report.  (Or, just have the timing tool report all paths in detail, not 
just the failing paths.)

JTW


<u_stadler@yahoo.de> wrote in message 
news:ae7fc722-f000-44a5-b852-7d53946cb99d@x41g2000hsb.googlegroups.com...
>i forgot mention that i did a static timing analysis with the timing
> analyzer.
> i also looked into the manual for trace but i would rather have some
> examples if there are some.
> thanks 


0
jtw
3/23/2008 5:19:30 AM
Reply: