Timequest Help needed for proper analysis

[Altera_Forum]

HI, all i am quire new bie to timing verification. 

 as per datasheet and alterforum, i able to constranin the design. but i can't able to analysis the result. i notice from the timeqeust clock network delay is 3.9 ns, how to reduce this delay.   here is the constrain and errors in jpg, any reply is highly apprieciated.    # # DEVICE "EP2S60F1020C5"  set_time_format -unit ns -decimal_places 3  # ************************************************************** # Create Clock # ************************************************************** create_clock -name {H1_IN} -period 14.705 -waveform { 0.000 7.352 } [get_ports {H1_IN}] -add create_clock -name {DOT_CLOCK} -period 2.941 -waveform { 0.000 1.470 } [get_ports {DOT_CLOCK}] -add create_clock -name {DOUBLE_SEL_CLK} -period 2.941 -waveform { 0.000 1.470 } [get_ports {DOUBLE_SEL_CLK}] -add create_clock -name {CLK_IN} -period 14.925 -waveform { 0.000 7.462 } [get_ports {CLK_IN}] -add  # ************************************************************** # Create Generated Clock # **************************************************************  create_generated_clock -name {DOUBLE_SEL} -source [get_ports {DOUBLE_SEL_CLK}] -divide_by 2 -master_clock {DOUBLE_SEL_CLK} [get_nets {CLK_DIV|lpm_counter_component|auto_generated|safe_q[0]}] -add create_generated_clock -name {DOUBLE_CLK} -source [get_ports {DOUBLE_SEL_CLK}] -master_clock {DOUBLE_SEL_CLK} [get_keepers {inst1240}] -add derive_pll_clocks -use_tan_name  # ************************************************************** # Set Clock Groups # ************************************************************** set_clock_groups -exclusive -group [get_clocks { altpll0:inst21|altpll:altpll_component|_clk0 CLK_IN }] -group [get_clocks { DOT_CLOCK }] -group [get_clocks { DOUBLE_SEL_CLK }] -group [get_clocks { H1_IN }]   regards,  baba

[Altera_Forum]

The attached failing path is a minimum pulse width, which isn't do to a 3.9ns clock delay. It comes directly from your 2.941ns clock period. What device and speed grade are you targeting? It looks like the memory is only able to run at (1/(2*1.597) = 313MHz, while you're trying to run it faster. (The requirement is not really the clock period, but a minimum high and low time, which is more relevant if your duty cycle isn't 50/50.) But it sounds like your running into a spec'd limit. The Globals, Memories, I/O and possibly other hard components have maximum rates they can run at, even if the micro-timing analysis says it can run faster. A common example is if your clock domain were two registers and nothing else. From a static timing analysis, they may only have a 1ns data delay, so they could technically run at 1GHz, but the global clock tree could never toggle that fast for capacitive and other reasons, so you would get a min pulse width error.

[Altera_Forum]

Rysc is correct about the minimum pulse width violations. I suspect you asked about the clock network delay because of your setup violations. 

 The clock network delay magnitude does not matter for internal paths (it could matter for I/O paths). What does matter is the clock skew from the difference between the clock network delays in the data arrival path and data required path. Clock skew is reported on the Statistics tab of the Report Timing window in the TimeQuest GUI. Small skews are normal even for global clocks. If this skew is bigger than around 0.1 ns, check to see whether the clock for one of the registers has combinational logic in the clock path. See http://www.alteraforum.com/forum/showthread.php?t=2388 for more information about issues with logic in the clock path.  The clock network delay line in the report represents the total delay for everything in the clock path. To see what is in the clock path, run report_timing with the "-detail full_path" argument. In the Report Timing dialog box, set "Detail level" to "Full Path". You will see how the clock goes from a device pin through any PLL(s), clock control block(s) for global buffers, and combinational logic to the source or destination register.  If you still have negative setup slack after you've taken care of any problems causing excessive clock skew, try the recommendations shown in Quartus at "Tools --> Advisors --> Timing Optimization Advisor" under "Maximum Frequency (fmax)".

[Altera_Forum]

Hi Rysc and Brad,  

 Thanks for a reply, My deivce is EP2S60F1020C5 and i noticed in setup time, slack is -6.048. and end point tns is -11072.420. (why this value is so high) i dont know. please reply , please dont think the question is too silly,(because i am entirely new to this).  thanks and regards, baba

[Altera_Forum]

yes, i want to run the design at 340 Mhz

[Altera_Forum]

--- Quote Start ---  ... i noticed in setup time, slack is -6.048. and end point tns is -11072.420. (why this value is so high) i dont know.  --- Quote End ---     Think of TNS (total negative slack) as being the sum of the negative slack of all the failing paths. It's not really that simple, but that gives you an idea of what it means.  I don't remember how the actual calculation was explained to me. A single source register going to a single destination register might have multiple paths between these two registers, and there might be more than one of these paths failing. TNS might be the sum of the negative slack for just the worst failing path of each source/destination register pair and not include the slack for the other failing paths for register pairs that have more than one path between them.  TNS gives you a metric for judging how bad the overall timing performance is. If slack is -6.048 ns and TNS is also -6.048 ns, you know you have only one failing path (or, based on my guess in the previous paragraph, maybe just one failing register pair that might have more than one failing path between those two registers). That might be easy to fix. If slack is merely -0.5 ns and TNS has a huge magnitude, you know you have lots of failing paths that need to be fixed. For your combination of -6.048 ns slack and -11072.420 ns TNS, you know without even running report_timing on this clock domain that you have many failing paths using this clock.

[Altera_Forum]

--- Quote Start ---  TNS might be the sum of the negative slack for just the worst failing path of each source/destination register pair and not include the slack for the other failing paths for register pairs that have more than one path between them.  --- Quote End ---     Maybe what I was told is that TNS is the sum of the single worst slack for every destination register with failing paths regardless of how many different source registers are involved in those failures. That would be consistent with the term "end-point TNS".  Whatever the calculation is, the purpose is just a metric to give you an idea of how bad the overall timing is as I described at the end of my previous post.

[Altera_Forum]

HI Bard, 

 Thanks for quick reply, Here is the my simple design attacment, i saw some setup time violations, i dont know how to correctly apply the constrains. help is highly higly apprieciated.  thanks all,  regards  baba