[Misunderstandings and Advanced Use of Vivado] Customizing Vivado Design Implementation Process with Tcl

The previous article "Application of Tcl in Vivado" introduced the basic syntax of Tcl and how to use Tcl to locate targets in Vivado. In fact, Tcl has many extended applications in Vivado. Next, we will discuss how to use the flexibility and scalability of the Tcl language to implement a customized FPGA design process in Vivado.

Basic FPGA design implementation process

Simply put, the design process of FPGA is the implementation process from source code to bitstream file. It is generally similar to the IC design process and can be divided into front-end design and back-end design. The front-end design is the process of synthesizing the source code into the corresponding gate-level netlist, while the back-end design is the process of placing and routing the gate-level netlist on the chip for final implementation.

The following two figures show the basic design flow of ISE and Vivado respectively:

Each step of the design implementation in ISE is a relatively independent process, and the data models are different. Users need to maintain different input files, such as constraints, etc. The output files are not in the standard netlist format and have different forms, resulting in a long overall running time and a large number of redundant files.

Vivado unifies the constraint format and data model, supports XDC constraints at any stage of design implementation, can generate timing reports, and outputs a design checkpoint (DCP) file containing netlist, constraints, and layout and routing information (if any) at each step, greatly shortening the running time.

In terms of usage, Vivado supports both project mode (Project Based Mode) and non-project mode (None Project Mode), and both can be run through Tcl script batch processing, or interactively run and debugged in the Vivado graphical interface IDE.

Engineering Mode

The key advantage of the project mode is that the entire design process can be managed by creating a project in Vivado, including the location of project files, the generation of key reports at different stages, the output and storage of important data, etc.

As shown in the left figure below, after the user creates a Vivado project, the tool will automatically create the corresponding .xpr project file and several corresponding directories at the same level as the project file, including <prj_name>.cache, <prj_name>.data, <prj_name>.runs, and <prj_name>.srcs, etc. (different versions may have slight differences), which are used to store data generated during the running of the project, output files and reports, and input source files (including constraint files) of the project.

As shown in the figure below, the entire design process can be run with one click in Vivado IDE. These preset command buttons are placed in the leftmost sidebar of the tool: Flow Navigator. Different buttons correspond to different implementation processes. In the back-end implementation stage, you can also use the right button to call out detailed step-by-step commands to guide the tool to execute which specific step of the implementation.

It is particularly important to point out that the Flow Navigator will only be displayed when the .xpr project file is opened in the Vivado IDE. If a design checkpoint .dcp file is opened (regardless of whether the dcp is generated in project mode or non-project mode), this sidebar will not be displayed.

Non-engineering mode

In non-project mode, since no project will be created, users need to manage the design source files and design process by themselves. Source files can only be accessed from the current location. At each step in the design implementation process, data and operation results exist in the machine memory allocated by Vivado, and will not be stored on the hard disk unless the user actively outputs them.

Simply put, the non-engineering mode provides a process similar to ASIC design. Users have absolute freedom and can fully control the design implementation process, but they are also required to be fully responsible for the design implementation process and data, especially file output and management, including when, where, and what kind of files to output.

Using non-engineering mode to manage input and output files and implement designs requires the use of Tcl scripts, but this does not mean that non-engineering mode does not support graphical interfaces. The .dcp files generated in non-engineering mode can also be opened in Vivdao IDE, and then various reports can be generated, and interactive debugging and other operations that are more convenient and intuitive in graphics can be performed. This is a common misunderstanding, just like many people mistakenly believe that Tcl scripts are not supported in engineering mode. However, the Tcl commands supported by the two modes are indeed completely different, and they should not be confused when used.

The following figure shows the different scripts used to implement the same design (Example Design provided by Vivado) in two modes. More details can be found in UG975 and UG835. It should be noted that the Tcl script in the engineering mode is more concise, but it is not the lowest-level Tcl command. Actually executing one is equivalent to executing several Tcl commands in the non-engineering mode.

Two types of Tcl scripts supported by Vivado

Tcl's supplement to graphics

I believe that for most FPGA engineering designers, the graphical interface is still the most familiar operating environment and the first choice for design implementation. This has not changed after Xilinx launched Vivado, which fully supports Tcl. However, we would like to point out that even when running designs on the graphical interface, you can still make full use of the advantages of Tcl. There are several main channels for running Tcl scripts on Vivado IDE.

Tcl Console

There is a Tcl Console at the bottom of the Vivado IDE, which allows users to enter Tcl/XDC commands or source pre-written Tcl scripts during operation, and the return value will be displayed in this dialog box immediately.

For example, during the design debugging process, some constraints need to be applied to certain netlist targets (for details, please refer to "Application of Tcl in Vivado"). The recommended approach is to open the .dcp in the IDE and then enter the corresponding Tcl/XDC command in the Tcl Console to verify the return value. If you encounter a problem, you can modify it directly until you find the correct and appropriate command. Then you can record these commands and save them in the XDC file for use in the next implementation.

There is also a situation where some constraints in the pre-read XDC need to be modified, or some important constraints are missing. Unlike the practice in ISE where you must modify the UCF and rerun the design, in Vivado, we can take full advantage of Tcl/XDC and enter new Tcl/XDC in the Tcl Console. There is no need to rerun the design, just run the timing report for verification. Of course, if the design can be rerun, the effect will be better, but this method provides a possibility for fast interactive verification in the early design stage, ensuring faster design iterations and greatly improving efficiency.

In addition, with the help of certain Tcl commands (such as show_objects, select_objects, etc.), we can also use the Tcl Console to interactively debug with timing reports, RTL and gate-level netlists, and netlists after layout and routing, giving full play to the advantages of Vivado IDE.

Hook Scripts

Vivado IDE has built-in tcl.pre and tcl.post, which users can find in the Synthesis and Implementation settings windows. Each step of the design implementation has two locations for users to add their own Tcl scripts.

tcl.pre indicates the Tcl script that Vivado will actively source before the current step, and tcl.post indicates the script that will be sourced after this step. The Tcl script must be written in advance, and then the user can specify the location of the script using the pop-up window in the setup interface shown in the figure above.

These are so-called "hook" scripts, which allow us to enjoy the convenience of one-click execution on the graphical interface and make full use of the extensibility brought by Tcl. A common usage scenario is to generate several special reports after a certain step, or to run physical optimization several times before routing.

Customer Commands

Vivado IDE also has an extension function that allows users to add pre-created Tcl scripts to the graphical interface as customized commands, turning them into a button for quick execution. This function is often used to report specific timing information, modify netlist content, implement ECO, etc.

Customize the implementation process with Tcl

In summary, the standard FPGA design implementation process can be fully executed with one click through the Vivado IDE. If only a small amount of expansion is required, it can also be done through the aforementioned hook script and other methods. If these methods cannot meet the needs, you can also use Tcl scripts to run the design, thereby achieving full customization of the design process.

Note: The following implementations only include the differences in the specific steps of backend implementation, and only list the corresponding Tcl commands in non-engineering mode.

The following figure shows the basic flow of design implementation in Vivado. The blue part represents the basic steps of implementation (although opt_design is not a required step in theory, it is still strongly recommended for users to perform it), corresponding to the Default strategy of Implementation. The yellow part represents the optional execution part, which has different configurations in different implementation strategies.

We will not discuss the strategies available in the graphical interface here. The focus of different strategies and how to configure them will be described in detail in another article about Vivado strategy selection. What we want to show is how to modify the design process to better meet the design requirements, which can often only be achieved through Tcl scripts.

Take advantage of physics optimization

Physical optimization, or phys_opt_design, is an important means of timing optimization in the back end by copying and moving registers to reduce fan-out and retiming. It is usually run between placement and routing. Starting from Vivado 2014.1, it also supports physical optimization after placement.

Many users will select phys_opt_design in Vivado, but they often don’t know that this step can actually be run multiple times and different directives can be selected to optimize timing in a focused manner.

For example, we can write a Tcl script that runs multiple physical optimizations after layout using different directives or options, or even run one more physical optimization specifically for those high fanout nets that were found in advance by the get_nets command and defined as highfanout_nets. The specific meaning of the directive can be queried through UG835, UG904, or the phys_opt_design -help command.

Multiple physical optimizations between placement and routing will not deteriorate timing, but will add extra runtime and may result in timing not being optimized at all. Physical optimization after routing can sometimes deteriorate THS, so please remember to run report_timing_summary after each step and write a .dcp file through write_checkpoint to preserve the interim results. If the result of this step is not ideal, you can return to the .dcp file of the previous step and continue.

Closed-loop design process

The usual FPGA design process is an open-loop system, which is executed from front to back. However, Vivado provides a possibility that users can perform another layout and routing on the design that has already completed the layout and routing through place_design -post_place_opt, thus forming a closed-loop system with feedback information. This time, because of the real connection delay information after the previous routing, the layout is more targeted, and only the paths that do not meet the timing will be re-laid out without changing most of the existing layout information. The subsequent routing process is also an incremental process.

This process takes a short time to run and is a very targeted timing optimization solution. You can write a loop in Tcl and run it multiple times, but you need to pay attention to the timing report each time and stop in time if the timing deteriorates.

Incremental Design Flow

Incremental design in Vivado is also a feature that must be mentioned. When the design is in the later stage, the changes are small each time, and the design netlist read in before starting the back-end implementation has a high degree of similarity, it is recommended to use Vivado's incremental placement and routing function.

As shown in the figure below, the prerequisite for running the incremental process is to have a .dcp file that has completed the layout and routing, and use it as a reference for the new layout and routing.

During the run, Vivado reuses existing placement and routing data to shorten the run time and generate predictable results. When the design has more than 95% similarity, the run time of incremental placement and routing is 2 times shorter than that of general placement and routing on average. If the similarity is less than 80%, there is little or no advantage in using incremental placement and routing.

In addition to shortening run time, incremental placement and routing causes little disruption to the parts of the design that have not changed, thereby reducing timing changes and retaining timing results to the greatest extent possible. Therefore, it is generally required that the .dcp file used as a reference must be a design with complete timing convergence.

The reference point .dcp file can be specified in the Implementation settings of the Vivado IDE, or read in using read_checkpoint -incremental in a Tcl script. It is particularly important to point out that in engineering mode, if you want to use the results of the previous run as a reference point without creating a new impl implementation, you must save it to a location other than the current run directory, otherwise an error will be reported due to a conflict.

The above discussion on using Tcl to customize the Vivado design implementation process ends here. More detailed Tcl usage scenarios, including ECO processes, will be expanded separately. Please pay attention to more technical articles on the Xilinx official website and Chinese forum.

---> END <---