Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Output_Pin tming not met in TimeQuest.

Hi

I have a problem in TimeQuest.

Timing requirement mot met from regster to output_pin.

//**********************

My .sdc file contain following commands

set_output_delay -max 0.2 -clock $rd_clk [get_ports out_data

[*]]

set_output_delay -min 0.1 -clock $rd_clk [get_ports out_data

[*]]

set_output_delay -max 0.2 -clock $rd_clk [get_ports out_data_vld]

set_output_delay -min 0.1 -clock $rd_clk [get_ports out_data_vld]

** max,min delay are ideal value. I can modify them.

//**********************

and I set "FAST_OUTPUT_REGISTER ON -to out_data_vld","FAST_OUTPUT_REGISTER ON -to out_data",

and "PHYSICAL_SYNTHESIS_EFFORT EXTRA"

in qsf file.

so I think this is phisical problem.

No effect changing with "Physical systhesis effort" && "Preform register duplication".

What should I do?

Do I have to give up to use this device in this frequency?

Thanks!

8 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    It is a quite tight requirement... It depends on what you require. One option is to use a pll to shift the clock that you output, so that it is in sync with your signals.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    What's $rd_clk? You have a clock delay of -3.452ns on the latching clock. Since your requirement was originally 5ns, and taking 3.452ns off, you're really asking for an extremely tight requirement.

    I'm guessing the -3.452ns is wrong. Note that your -clock option should generally be a virtual clock(i.e. it's not applied to anything physical on the FPGA). Something like:

    create_clock -name rd_clk_ext -period 5.0

    set_output_delay -clock rd_clk_ext

    There are a number of other posts about this, but hopefully that helps. (I'm not sure if your source clock is correct either, with a delay of 0.14. I would run the report_timing command with the option -detail full_path, and then make sure it traces all the way back to the input clock port.)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    One followup to Daixiwen's comment. This is actually a very loose requirement, probably impossibly loose. All it says is that the external board and device chew up 100ps of the data period. set_output_delay is not a requirement on what the FPGA has to meet, but saying what the external devices have already met, and the FPGA's requirements are based on that. For example, the clock period seems to be 5ns. The external -max delay is 200ps, so that means the FPGA has 4.8ns of that clock period to work with. Yes, 4.8ns can be tight to get a signal out in, but still, the whole data period is being given to the FPGA, not the external device. (I think the poster said those numbers could/would be changed..)

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    I'm having a similar problem, except that I have PLL and I think I have constrained everything correctly. Here's my timing report: 

    
Data Arrival Path
Total Incr  Type  Element
----- ----- ---- --------
0.000 0.000       launch edge time
0.326 0.326       clock network delay
0.558 0.232 uTco  out~reg0
0.558 0.000 CELL  out~reg0|q
2.203 1.645 IC    out~output|i
4.355 2.152 CELL  out~output|o
4.355 0.000 CELL  out
Data Required Path
Total  Incr  Type Element
----- ------ ---- ---------
5.000  5.000      latch edge time
5.000  0.000      clock network delay
4.910 -0.090      clock uncertainty
3.410 -1.500 oExt out
    As you can see, I have "set_output_delay 1 [get_ports out] -clock clk", and clk has been compensated with PLL. However, there's still non-zero clock tree delay and the IOOBUF has a really big delay.

    What can I do to close the output timing? Note that I need ~1ns improvement. So even if the clock tree has 0ns insertion delay it won't help.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hi,thanks for the reply.

    >wuz73

    I'm really sorry,

    My constrains met ,

    but set_output_delay -max was "minus" value.

    set_output_delay -max [ Tdata_Max - Tclkskew_Min + Tsu ]

    I think it should be "plus" value.

    and "minus" is not realistic....
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    wuz73, clock tree delays are never 0, even with a PLL, and they don't account for output buffers, whcih are generally pretty big. You could shift your clock back in time 1ns(and add a multicycle -setup 2), so that your setup requirement goes from 5ns to 6ns(and you'd have a 1ns hold requirement.)

    Note that you're doing a 200MHz I/O interface. Those speeds are where you start having to do things source synchronously, although it's kind of at the edge. (Also, what I/O standard is it. Things like LVDS are often used here, but of course that uses two pins...)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hi wat_arg,

    See the earlier posts about the timing constraints, they are right on.

    As to changing the time required for a signal to get out of your device, you can only control a few minor things:

    > make sure the register is moved to an I/O register

    > make sure you have a strong drive strength - the tCO will be affected by your I/O standard, voltage, and slew rate / drive strength

    After that you will probably start to look at clock skew, which earlier replies allude to when they talk of using PLLs.

    good luck
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Rysc, thanks for your suggestion.

    Pardon me for my (rookie) question on mucking the clock, as I'm new to FPGA design. I have been doing ASICs and full-custom ICs for over 10 years. In full-custom IC, you always use multi-phase clocks, so that's relatively simple. In ASIC flows, adjusting clock phase by 1/5 for part of the clock tree is not only impractical but also not recommended. Moreover, it's a big NO whenever you mention "multi-cycle path" as it oftentimes creates nightmares. I'm just wondering -- is it common to do all these "highly unrecommended (for ASICs)" in FPGA?

    FYI, I'm using 3.3V LVTTL/LVCMOS (singled-ended) in Cyclone3 device. Also I can't use source-synchronous on the clock because it's generated off-chip. One thing I can do is to generate a return clock and let the receiver device to sync the signals back to the original clock domain, but that obviously introduces other problems. In my case, the killer is latency.

    I noticed that some of my output signals have smaller input and/or output delay in the IOOBUFs and thus do meet timing. Is there anything I can do to help Quartus minimize the input/output delays?