Forum Discussion

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

tiny hold violations in Cyclone III, 1200 mV 0C

I have a design in a Cyclone III EP3C25F324C8. It is fully constrained and passes all timing tests in TimeQuest except that it has tiny hold violations under MIN_fast_1200mv_0c conditions. A chip planner image of two of them is attached (LCCOMB_X11_Y22_N12). These are inside an NCO generated by the Altera NCO compiler. I have done all the things suggested by the Timing Optimization Advisor for hold violations. All of the violations are very small, 10-20 ps. Can I get rid of them? Should I be worried about them? This design does have to work reliably 0 - 65 C. Thanks!

6 Replies

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

    What version of Quartus? (Some older versions had issues). I know you said you checked everything, but the main two are Assignments -> Settings -> Fitter, and make sure Hold Optimize is set to All Paths and Optimize Multi-Corner Timign is checked.

    (Again, you may have done all this but wanted to make sure.)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Its Quartus 9.0SP2. Yes, these assignments are both checked. One thing that might be related is that I always get the warning "Timing driven synthesis is skipped..." I have asked some questions about this in anther thread but don't understand it yet. Thanks for your comments.

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

    I noticed the delay is 3.067ns. Can you attach the timing report(I'm not sure if that's the data delay, or the clock + data delay). If it's the data, then you have a large positive hold requirement. Is that expected?

    Or is the hold requirement 0ns, and it's just a really fast path?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Here is the report (extension changed from rpt to txt). Paths 1-16 have larger hold violations that have to do with a DAC. I think I know what to do about those.

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

    Interesting. Note that these are all registers feeding back on themselves. I believe their is a dedicated feedback path that is very fast for this, and the router(which is what adds delays to meet hold timing) can't break that path, which is why the options aren't helping.

    That being said, the timing models are supposed to be setup where this doesn't cause a hold violation to begin with. Can you file an SR, as this should be fixed. (What device, out of curiosity).

    For peace of mind, note that it is absolutely impossible to get a hold violation when the same register is the source and destination and the requirement is 0ns. Basically the data delay would have to physically be negative to get a hold violation. The reason timing analysis catches it is because a lot of uncertainties, jitter, etc. are built into the model and are valid for all transfers except this special case. I would ignore it until it gets fixed. You could also add:

    set_clock_uncertainty -hold -0.233 -from <clock_name> -to <clock_name>

    to the clock domain. This would artificially remove uncertainty and allow it to meet timing. I'm not a big fan of this though.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Thanks very much, your comments are extremely helpful. The device is a Cyclone III EP3C25F324C8 on a Cyclone III Starter Board. I will file an SR.