Forum Discussion

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

New bie on timing constraints

Hello Experts,

I have been new in Altera & Quartus.

I am trying to understand the need for constraints like 'set_clock_latency' , 'set_clock_uncertainity' in FPGA's.

For me these constraints looked to be more appropriate for ASIC's when compared to FPGA's. The reason being, all clocks in FPGA's are generated by DCM/PLL where the tool itself should have the required library delay models for all these clock generation primitives.

In that case, do the user needs to really care about applying these constraints of source latency and clock jitter through clock uncertainty commands,

I really appreciate if you can help me understand with an example where usage of these constraints are very much important for clock modelling.

Can everyone pitch in and share your thoughts (please don't ask me to refer manual since i am not looking for a syntax help here rather trying to understand the real application of these commands in FPGA's).

Many thanks in advance;

Regards,

frk

10 Replies

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

    derive_clock_uncertainty calls out set_clock_uncertainty for each transfer, so you don't need to do this yourself. (And derive_clock_uncertainty gets called automatically). You could use it to model jitter on an external(virtual) clock, but I never seen that done.

    I've seen set_clock_latency used to model external clock delays. For example, if two clocks are coming in that are related, you could have different latency on the two clocks and their relationships inside the FPGA will now be altered. Very seldom needed, and when I've seen it, most users just modify the clock waveform to get similar results.

    In the end, most designs never use these. My 2 cents, but I'll be curious what others say...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    You are right about PLLs but the compiler wouldn't know your clock if it is external. Moreover the compiler wouldn't know the timing pattern required for io so you need to tell it. It also needs help to set false paths or multicycles(these may be automated in future!)

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

    One use of clock jitter (in dspbuilder) is to force it do better fmax at the expense of resource. DSPbuilder does not accept setting sys clk to incorrect higher value so here jitter is practical for tool.

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

    Very rare to need them. But useful to have when needed.

    set_clock_uncertainty:

    - add a "just in case" safety margin

    - add a safety margin to account for jitter in the input clock

    set_clock_uncertainty or set_clock_latency (the latter is more appropriate here):

    - model external delay variance, when the FPGA has two or more related clock inputs.

    On ASICs, the most common use of set_clock_uncertainty is actually to add a margin for clock skew during synthesis and place, as the clock tree is not yet built and the real skew is unknown.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Thanks for sharing your thoughts.

    @Kaz,

    I was just curious to understand, how setting 'clock_latency/uncertainity' would be helpful is setting false/mcp's. I could not make out the relation. Can you please elaborate on this point.

    Also, what is dsp builder. I assume this is something to do with DSP core generator.

    Here, again shall we live by giving input delays since there is not CTS like ASIC in FPGA.

    @rbugalho,

    My understanding is, even if FPGA has one or more clock inputs, the DCM output will be stable and jitter free. I suppose that is how PLL primitives are mad for.

    In that case, do we need this kind of modelling.

    Have you guys seen this anytimes using this constraints if the chip top level or clock coming from ALTPLL, DCM/PLL etc.

    Regards,

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

    --- Quote Start ---

    Thanks for sharing your thoughts.

    @Kaz,

    I was just curious to understand, how setting 'clock_latency/uncertainity' would be helpful is setting false/mcp's. I could not make out the relation. Can you please elaborate on this point.

    --- Quote End ---

    I misunderstood your specific question. There is no relation of false path/MCP to clock delay or uncertainty. I just wanted to point out that these should be possible candidates for automation in near future!

    clock jitter can be entered if you know your figure. This will in effect lower the clock period.

    clock delay is something I never use.

    --- Quote Start ---

    Also, what is dsp builder. I assume this is something to do with DSP core generator.

    Here, again shall we live by giving input delays since there is not CTS like ASIC in FPGA.

    --- Quote End ---

    Yes DSPBuilder is Altera's tool to generate rtl for various dsp functions and it has strict rule to enter exact clock speed so you can't add a bit of edge to improve fmax should it not meet timing.

    In normal work I may want to increase clock jitter to get better fmax for a given clock speed or I may equally do that by adding a bit of edge to the actual clock speed. The latter can't be used with dspbuilder.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Yes, we need this kind of modeling. Even though the PLLs filter jitter, their output is not totally jitter free.

    If you take a look at TQ's timing reports, you'll notice that "derive_clock_uncertainty" adds uncertainty to all clocks.

    But we don't have to do this modeling ourselves, most of the time.

    We usually can safely assume jitter in the input clocks is zero and let derive_clock_uncertainty do the work for us.

    I know I rarely do.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Thank you all.

    So in summary, there is no requirement to add 'clock_latency/uncertainity' for FPGA based designs since this should be taken care by default.

    Do you all agree ?

    Regards,

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

    In summary, most of the time, yes.

    But if your design has multiple related clocks coming into the FPGA, you'll probably need to use use set_clock_latency to model that.

    If you have a high jitter clock and can't afford to use a PLL to filter it, you should also use it.

    Those are rare situations; but it's best to know they exist.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Actually, I talked about multiple related clocks, but I forgot about the more applicable one, which again is for I/O constraints. For example, if you have an oscillator driving an external device and the FPGA, and it takes 1ns to get to the external device and 2ns to get to the FPGA, then you can add latency of 1ns to the virtual clock and 2ns to the FPGA clock. Now your clock delay/skew will be modeled in your I/O timing. If the external device has a Tco of 8ns and minTco of 4ns, you can just do a set_input_delay -max 8 and another set_input_delay -min 4. (Most users rolls the clock skew into this delay, which would make the -max value 7 and -min 3, but set_clock_latency will do this for you).