Validating at Each Design Stage - 2024.2 English - 2024.1 English

UltraFast Design Methodology Guide for FPGAs and SoCs (UG949)

Document ID
UG949
Release Date
2024-11-13
Version
2024.2 English

The UltraFast design methodology emphasizes the importance of monitoring design budgets, such as area, power, latency, and timing, and correcting the design from early stages as follows:

  • Create optimal RTL constructs with AMD templates, and validate your RTL with methodology DRCs prior to synthesis, after elaboration.

    Because the Vivado tools use timing-driven algorithms throughout, the design must be properly constrained from the beginning of the design flow.

  • Perform timing analysis after synthesis.

    To specify correct timing, you must analyze the relationship between each master clock and related generated clocks in the design. In the Vivado tools, each clock interaction is timed unless explicitly declared as an asynchronous or false path.

  • Meet timing using the right constraints before proceeding to the next design stage.

    You can accelerate overall timing and implementation convergence by following this recommendation and by using the interactive analysis environment of the Vivado Design Suite.

    Tip: You can achieve further acceleration by combining these recommendations with the HDL design guidelines in this guide.

The following figure shows this recommended design methodology.

Figure 1. RTL Design Methodology for Rapid Convergence Page-1 Standard Arrow.40 Sheet.41 Run Synthesis Review options & HDL code Run SynthesisReview options & HDL code Standard Arrow.42 Sheet.43 Define & Refine Constraints Define & Refine Constraints Standard Arrow.44 Decision.45 Timing Acceptable? Timing Acceptable? Sheet.46 Place & Route Place & Route Sheet.47 Standard Arrow.48 Sheet.49 Cross-probe Instances in critical path In Netlist view and El... Cross-probeInstances in critical pathIn Netlist view andElaborated view schematics Sheet.50 N N Sheet.51 Y Y Sheet.53 report_clock_networks -> create_clock / create_generated_cloc... report_clock_networks -> create_clock / create_generated_clockreport_clock_interaction -> set_clock_groups / set_false_pathcheck_timing -> I/O delaysreport_timing_summary -> Timing exceptions Sheet.54 X13422 X13422 Sheet.52

Synthesis is considered complete when the design goals are met with a positive margin or a relatively small negative timing margin. For example, if post-synthesis timing is not met, placement and routing results are not likely to meet timing. However, you can still go ahead with the rest of the flow even if timing is not met. Implementation tools might be able to close timing if they can allocate the best resources to the failing paths. In addition, proceeding with the flow provides a more accurate understanding of the negative slack magnitude, which helps you determine how much you need to improve the post-synthesis worst negative slack (WNS). You can use this information when you return to the synthesis stage with improvements to HDL and constraints.