Forum Discussion

zjj's avatar
zjj
Icon for New Contributor rankNew Contributor
1 month ago

timing violation fix

hi,   I am working on the project that base on agilex 7 fpga. 

project background:

  1. the compile setting is superior performance, sys clock is 416Mhz
  2. the ALM resources of the project has occupied the 70%,  and  has WNS -0.9 ns, TNS -29ooo ns violation.   

do you have better metholodgies for timing fix？ 

now my work flow:

  1. first analyze the fit.retiming.rpt and fit.fastforward.rpt, add pipe or register according to critical chain reported in the retiming.rpt,
  2. then start to next compile

I doesn't analyze the fit.timing.rpt,  because the endpoint is too large, and the work efficiency is low

Timing

5 Replies

  • BobC_Altera's avatar
    BobC_Altera
    Icon for New Contributor rankNew Contributor
    1 month ago

    Hi zjj

    What kind of timing violations are present?

    Please see these guides:

    Quartus Prime Pro User Guide Design Optimization - Timing Closure

     AN 903: Accelerating Timing Closure in Quartus Prime Pro provides information on rapidly resolving timing issues.

    AN 584: Timing Closure Methodology for Advanced FPGA Designs

    Hyperflex Architecture High-Performance Design Handbook

    Here is a general work flow I use to solve timing issues:

    • Fix incomplete/incorrect SDC constraints first
      • Design Assistant can help in finding clock crossings that have not been set to false_path as well as other issues
      • I look for the high severity items
    • Resolve setup violations via retiming and pipelining
      • See the guides above for QSF settings 
    • Let Quartus auto-fix hold violations; manually intervene only if needed
      • Search for KDBs related to hold violations
    • For setup violations that are greater than ~200 pS, check the path in Timing Analyzer
      • In Timing Analyzer GUI, under Tasks - Macros: run Report Top Failing Paths
      • Check the worst failing paths to see levels of logic and routing delay
      • Can levels of logic be reduced without major impact to design? If yes, then change, if no, keep looking
      • Is routing delay long relative to clock period?  If yes, then see Physical Synthesis Options these setting may help
    • Try multiple Fitter seeds before making RTL changes
    • Use Design Space Explorer II for systematic exploration
    • Consider larger RTL changes to reduce logic levels
    • Do all logic functions need to run at 416 MHz?  Can some regions with slower clock?
    • Consider reducing clock frequency or increasing device speed grade as a last resort

     

    Hope these notes help.

    Best regards,

    Bob

    • zjj's avatar
      zjj
      Icon for New Contributor rankNew Contributor
      1 month ago

      thank you for replay!

      the main is setup violation with 416Mhz!   there are 416Mhz and 208Mhz clock domain, some region is worked in the 208Mhz! 

      • KennyT_altera's avatar
        KennyT_altera
        Icon for Super Contributor rankSuper Contributor
        30 days ago

        If the main issue is setup violation at 416 MHz, while part of the design already runs at 208 MHz, then the next step is to focus on the remaining critical paths in the 416 MHz domain and also confirm that the crossings between the 416 MHz and 208 MHz domains are constrained correctly.

         

        A practical approach is:

         

        - First verify the SDC constraints for the 416 MHz and 208 MHz clocks.

          - If the clocks are related, keep normal timing analysis between them.

          - If any crossings are functionally asynchronous, apply proper CDC handling and timing exceptions.

         

        - Then group the failing setup paths into:

          - 416 MHz to 416 MHz

          - 416 MHz to 208 MHz

          - 208 MHz to 416 MHz

         

        - Prioritize the recurring 416 MHz to 416 MHz failures first, since these usually determine whether the design can meet 416 MHz.

         

        - For the worst failing 416 MHz paths, check:

          - logic depth

          - routing delay

          - high fan-out control signals

          - RAM/DSP/FIFO boundaries

          - reset or clock-enable impact

         

        - For Agilex 7 specifically, also check whether Hyper-Retiming is being limited by:

          - insufficient pipeline stages

          - asynchronous resets

          - wide broadcast clock enables

          - FIFO full/empty style control feedback

          - congestion or long-distance routing

         

        - If some functions currently in the 416 MHz region do not need to run at full rate, moving them behind a registered interface into the 208 MHz region can help reduce setup pressure.

         

        So in short, the recommendation is not only to add more pipeline stages, but also to classify the failing paths by clock relationship and then focus on the repeated 416 MHz path families first.