Vivado Design Methodology: Synthesis, Implementation and Timing Closure - alex-aleyan/xilinx GitHub Wiki

References:

Docs/Links:

Notes :

  • WNS = Worst Negative Slack (ref).
  • TNS = Total Negative Slack (sum of the negative slack paths).
  • WHS = Worst Hold Slack.
  • THS = Total Hold Slack (sum of the negative hold slack paths).
  • Keep in mind:
    • At Synthesis (after Synthesis run is complete, but before Implementation is run):
      • Setup violations: must be resolved thru timing constrains.
      • Hold violations: ignored and will be resolved by the tool during implementation thru introduction of delays into logic path.
    • At Implementation (after Implementation run is complete)
      • Hold violation: should not occur at the completion of the implementation run.
      • Setup violations: ideally do not occur here; if occur, utilize logic optimization coding techniques in your design's code.

Vivado Reports:

  • Reports:
    • Post-Synthesis:
      • Report DRC (Design Rule Check).
      • Report Clock Interactions.
      • Report Timing Summary (report_timing_summary).
    • Post-Implementation:
      • Report DRC (Design Rule Check).
      • Report Clock Interactions (Black - no path between clocks exist, Green - 2 clocks interact and constrained, Yellow - partial false path, Red - clocks interact and constraints are missing).
      • Report Timing Summary (Check Timing, Intra-Clock Paths, Inter-Clock Paths, Unconstrained Paths).
      • report_design_analysis
        • xilinx youtube video)
        • report_design_analysis -h
        • UG835 - Vivado Design Suite Tcl Command Reference Guide.
        • UG904 - Vivado Implementation.
        • UG949 - UltraFast Design Methodology Guide.
      • Report Utilization
      • report_fanout_nets
      • report_failfast

Post-Synthesis (see At Synthesis above):

  • Perform
  • xilinx::designutils::report_failfast
  • Report Clock Interactions: Flow Navigator -> Open Synthesized Design -> Report Clock Interactions
    • Check Timed (unsafe) - indicates issues with constraints.
    • Check Partial False Path (unsafe) - indicates issues with constrains (CDC).
    • Resolve any negative WNS but ignore WHS (resolved during implementation by the tool by utilizing delay insertion).
  • Report Timing Summary: Flow Navigator -> Open Synthesized Design -> Report Timing Summary
    • Should not report any Setup violations; only Hold and Pulse Width??? are allows.

Typical Implementation Strategies to explore:

  • Default / High Performance synthesis strategies
  • Performance_ExploreWithRemap
  • Congestion_SSI_SpreadLogic_Low
  • Congestion_SSI_SpreadLogic_High

Show GENERIC values via tcl:

  • join [get_cells -hierarchical -regexp .*OMX3200_10G_INPUT_TOP_. ] "\n"
  • get_property C_PORT_ID [get_cells DUAL_QUAD_10G_INPUT_MODULE_1_I/A_QUAD_10G_INPUT_MODULE_I/GEN_10G_PORT_GROUP[1].OMX3200_10G_INPUT_TOP_I]
    3'b000
  • FIXME:resume with trying to put it into a list: https://stackoverflow.com/questions/43665075/get-result-of-tcl-exec-command-into-array 
    set output_list [get_cells -hierarchical -regexp *OMX3200_10G_INPUT_TOP_. ]
foreach line $output_list { 
    puts "$line: [get_property C_PORT_ID [get_cells $line] ]" 
}

Post-Implementation:

Quick notes from training:

Vivado can be launched in these 3 modes:

  • GUI launches as a gui: vivado -mode gui
  • TCL interactive tcl console: vivado -mode tcl
  • Batch file: vivado -mode batch -source <file.tcl> 

Non-Project mode:

  • UG835 - guide for Non-Project mode.
  • Use vivado -mode tcl or vivado -mode batch.
  • Must manually create checkpoints, and create reports.
  • Runs completely in memory and nothing is written to the disk unless the commands are used explicitly to write the reports and results.
  • Has an interactive mode (does he mean if I write an interactive script or the tool has an interactive option that will prompt me thru each stage of the run?)
  • Processes access the underlying database of your design - each process operates on a netlistand will modify the netlist or create a new netlist
  • Different netlists are used throughout the design process: Elaborated netlist, Synthesized netlist, Implemented netlist.
  • Easy interaction to database via Tcl commands: Query database, Enter constraints, Generate reports.
  • Most visualization and report commands can be done on the design in memory between steps including graphical visualization commands using the GUl and all report_* commands
  • Checkpoints: All files are collected together in a single design checkpoint (DCP) file.
  • To access a checkpoint and automatically make it the active design, use open_checkpoint  (creates in memory object and initializes it with the checkpoint content).
  • Alternatively, do read_checkpoint to load it in the project but not memory; link_checkpoint to open it in memory.
  • Crossprobing (opening rtl code from the device view and viceversa) is unavailable in the non-project mode since the checkpoint scope is limited to the stage the checkpoint is opened for.
  • When encountering the start_gui command and the opened up window, to continue once you are done with the GUI DO NOT JUST CLOSE THE GUI WINDOW (this breaks the tread of control and you will be unable to go back to tcl thread) BUT USE stop_gui COMMAND INSTEAD!!!
  • BUT USE stop_gui COMMAND INSTEAD!!!
  • Once the start_gui command opens up the GUI you can continue building the design in the GUI, but make sure to use the tcl commands in the opened up GUI and not the buttons - using the buttons you are mixing the project mode design flow with non-project which is dangerous. You can even use the gui for design analysis, constraints assignment, netlist modification (logic changes and debug core insertion).
  • Any command executed in the non-project mode, acts on the netlist currently in memory. Opening a checkpoint does exactly that - it loads the netlist version corresponding to that checkpoint (post synth, post map, post place, post route) and other content.
  • Use synth_design -rtl to run the synthesis up to elaborate stage and not full synthesis - produces the netlist of your design implemented with the generic technology (meaning not in Xilinx building blocks like slices, carry logic, individual Flipflops, block ram, distributed ram).
  • Once the design is fully synthesized, we can: Query the database with the get * commands and all helper commands, Set and report properties, Include pin planning and other I/O properties, Create and manage Pblocks (created during floor planning to specify the floor area to lock the part of the design to?) for floor planning, Create and validate constraints for implementation, Constraints can be entered using the Tcl Console via the read xdc command or by using the Timing Constraint Window in the GUI, Create and view schematics, Analyze the design hierarchy and utilization, Report clock networks, Generate timing reports using estimated delays, Write checkpoints.
  • Once the design is fully implemented, we can (almost all post synthesis operations can be performed on the implemented design): Querying the database with the get * commands and all helper commands, Entering constraints for later processes and what-if analysis (Constraints can be entered using the Tcl Console, via the read xdc command or by using the Timing Constraint window in the GUI), Creating and viewing schematics, Analyzing the design hierarchy and utilization, Viewing the placement and routing of the design, Reporting clock networks, Generating timing reports, Writing out results (bitstream), Writing out checkpoints.
  • Typical commands: synth_design, synthesizes the design, opt_design performs optimization, power_ opt_design performs power optimizations, place_design places the design, phys_opt_design performs physical optimizations solely for timing closure meaning it only affect paths that are failing timing (best done after place_design but before route_design; can be run right after route_design for small timing corrections), route_design routes the design.
  • Constrains actually applied to a net list or to be more precise to circuit elements found in the netlist.
  • Constraints can be applied as early as right after design elaboration (right before mapping). You have to add the constraints before the synth_design command for the tool to use the constraints after design elaboration. So what is synth_ design is comprised of besides elaboration and mapping?
  • Once constraints are added, they propagate down the design flow thus driving every step/process (syth_design,opt_design,  place_design, phys_opt_design, route_design) there after.
  • To use different constraints at different stage, use reset_timing thus removing all constraints from memory. In the past, people would over constraint the design prior the synthesis to force more aggressive mapping, and would use appropriate constraints prior place and route. This practice is discouraged today.
  • These project mode features are not supported in the non-project mode: No source or results management, No Flow Navigator, No cross-probing.
  • To run a tcl script from inside the vivado, do source
  • Commands:
    • synth_design - Synthesize a design using Vivado synthesis and open a design. Note: link design is automatically run when synth_design is run. 
    • opt design - Perform all netlist optimizations by default: sweep, retarget, constant propagation, LUT remapping.
    • power_opt_design (optional): Optimize dynamic power using intelligent clock gating (so disables/enables clocks or parts of the design to conserve energy?).
    • place_design (Optional): Post-place power_opt_design.
    • Post-place phys_opt_design (optional): Performs timing-based logic replication of high-fanout drivers in negative-slack paths.
    • route_design
    • Post-route phys_opt_design (optional)

Project mode & scripting:

  • Journal file vivado.jou is a great source for reverse engineering scripting of the Project mode.
  • Project summary dashboard can be configured with custom reports via report_configuration command.
  • Filesets are Vivado objects:
    • Source.
    • Simulation.
    • Constraints: vivado will write to the xdc file that has been designated as a target. Set up a dummy when creating constraints from GUI then copy results to your timing, pins, whatever.
    • Use get_filesets and get_files to query the files and filesets. 
  • In project mode, the Vivado Design Suite creates the In project mode, the Vivado Design Suite creates the directory structure for the project.
  • In project mode, the project status, sources, constraint files, and IP cores are managed automatically.
  • The Runs Manager handles the reading and writing of most files.
  • Many files exist in pre-determined locations in the project hierarchy.
  • Multiple runs configuration is supported in project mode.
  • In Project mode, the tool automatically write check points post optimization/synthesis, post placement, and post route.

TCL:

  • Vivado uses tcl 8.5
  • Help: help get_*, help get_cells, help - category <name of the category>

Run Stages:

  • Synthesis (link_design):
    • Turns RTL into Netlist (netlist later mapped, placed and routed by implementation).
    • Applies the supplied constraints.
    • Best to have  timing constrains (not sure if IO constraints matter for synthesis since it’s not mapping nor placing nor routing at this point) since the synthesis is timing driven!
  • Implementation:
    • Logical Optimization* (opt_design)
    • Power Optimization* (power_opt_design)
    • Placement (place_design)
    • Physical Optimization* (phys_opt_design) - the tool goes thru your design checking the failing paths only based on the constraints provided.
    • Routing (route_design)
  • Report (consistent among project and non-project modes):
    • Timing Analysis (report_timing_summary)
    • Bitstream generation (write_bistream)

Project mode typical script outline:

create_project # or use open_project 

add_files -norecurse (../a_file.sv)

add_files [glob ../src/*.sv]

ser_property library mylib [get_files -of_objects source_1 ../a_file ]

add_file -norecurse -filesets constrs_1 ../timing.xdc

set_propert target_constrs_file ../timing.xdc

create_run

launch_run synth_1;   wait_on_run synth_1

open_run synth_1 -name netlist_1

report_timing

report_powers

create_run impl_1

set_property steps.phys_opt_design.is_enabled true [get_runs impl_1]

launch_run impl_1;   wait_on_run impl_1

open_run impl_1

report_timing

report_powers

launch_run impl_1 -to_step bitgen;   wait_on_run impl_1

Non-Project mode typical script outline:

set outputDir ./TC_Data/bft_output 

file mkdir $outputDir

#STEP 1: setup design sources and constraints

read vhdl -library bftlib [ glob

•/Sources/hdl/bftlib/*.vhdl]

read_vhdl ./Source/hdl/bft.vhdl

read_verilog [glob ./Sources/hdl/*.v] 

read_xdc ./Source/bft_full.xdc

#STEP 2: run synthesis, report

utilization, timing estimate, write design checkpoint:

synth_design -top bft -part Xc7k70tfbg484-2 -flatten -file

rebuilt 

write_checkpoint -force $outputDir/post_synth

report_utilization -file $outputDir/post_synth_util.rpt

report_timing -sort_by group -max_paths 5 -path_type summary

opt_design $outputDir/post_synth_timing.rpt

power_opt_design

place_design

phys_opt_design

write_checkpoint -force $outputDir/post place

report_clock_utilization -file $outputDir/clock_util.rpt

report_utilization -file $outputDir/post place_util.rpt

report_timing -sort by group -max paths 5 -path type summary -file $outputDir/post place_timing.rpt

#STEP 4: run router, report actual, utilization and timing, write

checkpoint:

route design

write_checkpoint -force $outputDir/post_route

report_timing_summary -file $outputDir/post_route_timing_summary.pt report_utilization -file $outputDir/post_route_util.rpt

report_power -file $outputDir/post_route_power.rpt

report_dre -file $outputDir/post_imp_dre.rpt

write_verilog -file $outputDir/bft_impl_netlist.v

write dc -no fixed only -force $outputDir/bftimpl.xdc

#STEP 5: generate a bitstream

write_bitstream $outputDir/design.bit

set_property example:

  • set property generic SCHEDULER=1 [current fileset]
  • set property verilog define XBAR=1 [current fileset]
  • set property top fftTop [current fileset]
  • set property steps.phys_opt_design.is_enabled false [get runs impl 1]

Reports:

  • Vivado.log contains all the messages produced by the vivado. 
  • DRC report. 
  • clock networks
  • Timing summary .
  • Report timing.
  • Cross-probing allows you to related the component placed in the device view (right click -> go to source) all the way back to RTL code.

A netlist breaks down into next objects: 

  • nets (configurable interconnects that route/connect the cells?),
  • cells (configurable logic blocks),
  • ports,
  • pins!
  • clock

XILINX SRLs: https://support.xilinx.com/s/article/46511?language=en_US.

DRC Reports - addresses issues at the earlier stages.

FILES:

  • Upfront it’s best to have these before performing synthesis and implementation (helps with optimization of synthesis, place and route):
    • IO Placement.
    • Global timing constraints (clock and IO?). Added via constraint editor, wizard, templates.
    • Path exceptions (multi cycle path, false math, min/max delays).
    • DCP file? - Design CheckPoint File is actually a zip file of: a netlist (EDF format), constraints (xdc format), placement/route information (XDEF format).

HPS:

  • Xilinx moved from SDK to Vitas (still eclipse based). Vitas adds support for large multiprocessor heterogeneous systems.

IPs:

  • @ at 1:39 there is a good question about a short cut to creation of an IP block from source code.
  • IP integrator.
  • IP containers.
  • Remote IP.

Floor planning:

  • Creating via tcl commands example: 
    create_block scheduler
resize_block -add SLICE X172Y290:SLICE X185Y313 scheduler
add_cells_to_block scheduler (get cells my inst/SCHEDULER inst/*]
⚠️ **GitHub.com Fallback** ⚠️