Details of the Sample Script - Details of the Sample Script - 2026.1 English - UG894

The key steps of the preceding script can be broken down as follows:

1. Defines a variable, $outputDir, that points to an output directory and also physically creates the directory. The $outputDir variable is referenced as needed at other points in the script.
2. Reads the VHDL and Verilog files that contain the design description, and the XDC file that contains the physical and/or timing constraints for the design. You can also read synthesized netlists (EDIF or NGC) using the read_edif command.

   The Vivado Design Suite uses design constraints to define requirements for both the physical and timing characteristics of the design. The read_xdc command reads an XDC constraints file which is used during synthesis and implementation.

   Important: The Vivado Design Suite does not support the UCF format. For information on migrating UCF constraints to XDC commands refer to the ISE to Vivado Design Suite Migration Guide (UG911) for more information.

   The read_* Tcl commands are designed for use in Non-Project mode, as it allows a file on the disk to be read by the Vivado Design Suite to build an in-memory design database, without copying the file or creating a dependency on the file in any way, as it would in Project mode. All actions taken in the Non-Project mode are directed at the in-memory database within the Vivado tools. The advantages of this approach make the Non-Project mode extremely flexible with regard to the design. However, a limitation of the Non-Project mode is that you must monitor any changes to the source design files, and update the design as needed. For more information on running the Vivado Design Suite using either Project mode or Non-Project mode, refer to the ISE to Vivado Design Suite Migration Guide (UG911).

3. Synthesizes the design on the specified target device.

   This step compiles the HDL design files, applies the timing constraints located in the XDC file, and maps the logic onto AMD primitives to create a design database in memory. The in-memory design resides in the Vivado tools, whether running in batch mode, Tcl shell mode for interactive Tcl commands, or in the Vivado Integrated Design Environment (IDE) for interaction with the design data in a graphical form.

   Once synthesis completes, a checkpoint is saved for reference. At this point the design is an unplaced synthesized netlist with timing and physical constraints. Various reports like timing and utilization can provide a useful resource to better understand the challenges of the design.

   This sample script uses a custom command, reportCriticalPaths, to report the TNS/WNS/Violators into a CSV file. This provides the ability for you to quickly identify which paths are critical.

   Any additional XDC file read in after synthesis by the read_xdc or source commands is used during the implementation steps only. They are stored in any subsequent design checkpoints, along with the netlist.

4. Performs pre-placement logic optimization, in preparation for placement and routing. The objective of optimization is to simplify the logic design before committing to physical resources on the target part. Optimization is followed by timing-driven placement with the Vivado placer.

   After each of those steps, the reportCriticalPaths command is run to generate a new CSV file. Having multiple CSV files from different stages of the design lets you create a custom timing summary spreadsheet that can help visualizing how timing improves during each implementation step.

   Once the placement is done, the script uses the get_timing_paths command to examine the SLACK property of the worst timing path in the placed design. While the report_timing command returns a detailed text report of the timing path with the worst slack, the get_timing_paths command returns the same timing path as a Tcl object with properties that correspond to the main timing characteristics of the path. The SLACK property returns the slack of the specified timing path, or worst path in this case. If the slack is negative then the script runs physical optimization to resolve the placement timing violations whenever possible.

   At the end of Step 4, another checkpoint is saved and the device utilization is reported along with a timing summary of the design. This lets you compare pre-routed and post-routed timing to assess the impact that routing has on the design timing.

5. The Vivado router performs timing-driven routing, and a checkpoint is saved for reference. Now that the in-memory design is routed, additional reports provide critical information regarding power consumption, design rule violations, and final timing. You can output reports to files, for later review, or you can direct the reports to the Vivado IDE for more interactive examination. A Verilog netlist is exported, for use in timing simulation.
6. Writes a bitstream to test and program the design onto the AMD FPGA.