Vivado Design Suite Tutorial: Implementation

Transcription

1 Vivado Design Suite Tutorial: Implementation

2 Notice of Disclaimer The information disclosed to you hereunder (the Materials ) is provided solely for the selection and use of Xilinx products. To the maximum extent permitted by applicable law: (1) Materials are made available AS IS and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related to, arising under, or in connection with, the Materials (including your use of the Materials), including for any direct, indirect, special, incidental, or consequential loss or damage (including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of any action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx had been advised of the possibility of the same. Xilinx assumes no obligation to correct any errors contained in the Materials or to notify you of updates to the Materials or to product specifications. You may not reproduce, modify, distribute, or publicly display the Materials without prior written consent. Certain products are subject to the terms and conditions of the Limited Warranties which can be viewed at IP cores may be subject to warranty and support terms contained in a license issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe or for use in any application requiring fail-safe performance; you assume sole risk and liability for use of Xilinx products in Critical Applications: Copyright 2013 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Vivado, Zynq, and other designated brands included herein are trademarks of Xilinx in the United States and other countries. All other trademarks are the property of their respective owners. Revision History The following table shows the revision history for this document. Date Version Revision 04/26/ First publication 06/19/ Added a third lab, Manual Routing and Directed Routing, to the tutorial.

3 Table of Contents Revision History... 2 Vivado Design Suite Tutorial: Implementation... 5 Overview... 5 Software Requirements... 5 Hardware Requirements... 5 Tutorial Design Description... 6 Preparing the Tutorial Design Files... 6 Lab #1: Using Implementation Strategies... 7 Introduction... 7 Step 1: Opening the Example Project... 7 Step 2: Creating Additional Implementation Runs... 9 Step 3: Launching and Analyzing Implementation Runs Step 4: Analyzing Implementation Runs Using Modified Timing Constraints Conclusion Lab #2: Using Incremental Compile...19 Introduction Step 1: Opening the Example Project Step 2: Compiling the Reference Design Step 3: Create a New Synthesis and Implementation Run Step 4: Make Incremental RTL Design Changes Step 5: Setting the Incremental Compile Checkpoint Step 6: Compiling Incrementally Conclusion Implementation 3

4 Lab #3: Manual Routing and Directed Routing...33 Introduction Step 1: Opening the Example Project Step 2: Compiling the Reference Design Conclusion Implementation 4

5 Vivado Design Suite Tutorial: Implementation Overview This tutorial includes three labs, each of which seeks to demonstrate an aspect of the Xilinx Vivado implementation flow: Lab #1: Using Implementation Strategies Lab #2: Using Incremental Compile Lab #3: Manual Routing and Directed Routing Vivado implementation includes all steps necessary to place and route the netlist onto the FPGA device resources while meeting the design s logical, physical, and timing constraints. For more information about the design flows supported by the Vivado tools, see the Vivado Design Suite User Guide: Design Flows Overview (UG892). Software Requirements This tutorial requires that the Vivado Design Suite release or later is installed. Hardware Requirements The supported Operating Systems include Redhat 5.6 Linux 64 and Windows 64 and 32 bit. Xilinx recommends a minimum of 2 GB of RAM when using the Vivado tool. Implementation 5

6 Tutorial Design Description Tutorial Design Description The sample design used for Lab #1 consists of a small design called project_cpu_netlist. There is a top-level EDIF netlist source file, as well as an XDC constraints file. The sample design used for Labs #2 and #3 consists of a small RTL design called project_bft_core_hdl. The design includes both Verilog and VHDL RTL files, as well as an XDC constraints file. Both designs target an XC7K70T device. Small designs are used to allow the tutorial to be run with minimal hardware requirements and to enable timely completion of the tutorial, as well as to minimize the data size. Preparing the Tutorial Design Files You can find the files for this tutorial in the Vivado Design Suite examples directory at the following location: <Xilinx_2013.1_install_area>/Vivado/<version>/examples/Vivado_Tutorial Implementation 6

7 Introduction Lab1 Lab #1: Using Implementation Strategies Introduction In this lab, you will learn how to use strategies with design runs by: Creating multiple implementation runs with different strategies. Comparing the Default Strategy results to the results of other strategies. You will use the CPU Netlist example design that is included in the Vivado IDE. Step 1: Opening the Example Project 1. Load the Vivado IDE by doing one of the following: Launch the Vivado IDE from the icon on the Windows desktop. Type vivado from a command terminal. 2. From the Getting Started page, click Open Example Project and select the CPU (Synthesized) design, as shown in the figure below. Figure 1: Open Example Project Implementation 7

8 Step 1: Opening the Example Project 3. A dialog box appears entitled Project is Read-Only. Click Save Project As to specify a project name and location, as shown in the figure below. Figure 2: Save Project As The Vivado IDE displays project information in the Project Summary window. Because this is a netlist project, there are no options for synthesis in the Flow Navigator. As shown in the figure below, the Project Summary window shows that the next step in the design flow is Vivado implementation. Figure 3: Project Summary Window Implementation 8

9 Step 2: Creating Additional Implementation Runs Step 2: Creating Additional Implementation Runs Start by creating new implementation runs and changing the implementation strategy from the default. The sample design already contains one implementation run with the Vivado Implementation Defaults strategy. 1. From the main menu, select Flow > Create Runs. The Create New Runs wizard opens. 2. Click Next. 3. Select Performance_Explore as the Strategy for the run in the Configure Implementation Runs window, as shown in the figure below. Use the default settings for all other options. (Do not click Next yet, however.) Figure 4: Configure Implementation Runs Window 4. Click More in the Create New Runs window to create another run. 5. Select Area_Explore as the Strategy for the run. 6. Click More to create another run. Implementation 9

10 7. Select Flow_RuntimeOptimized as the Strategy for the run. Step 2: Creating Additional Implementation Runs The Create Implementation Runs window now displays three new implementations along with the strategy you selected for each, as shown in the figure below. Figure 5: Configure Implementation Runs Window Summary Implementation 10

11 Step 2: Creating Additional Implementation Runs 8. Click Next to view the Launch Options and select Do not launch now. 9. Click Next to view the summary. Figure 6: Launch Options Window 10. In the Create New Runs Summary page, click Finish. Figure 7: Summary Window Implementation 11

12 Step 3: Launching and Analyzing Implementation Runs Step 3: Launching and Analyzing Implementation Runs 1. In the Design Runs window, select all the implementation runs. 2. Click the Launch Selected Runs icon to open the Launch Selected Runs window. 3. Select Launch runs on local host and Number of jobs: 2 in the Launch Selected Runs window, as shown in the figure below. 4. Click OK. Two runs launch simultaneously; the others are queued. Figure 8: Launch Selected Runs Window Note: When the active implementation run (impl_1) finishes, you might see a prompt to Open Implemented Design, Generate Bitstream, or View reports (see figure below). Just click Cancel. Figure 9: Implementation Completed Dialog Box Implementation 12

13 Wait until all the runs have finished to analyze the results. Step 3: Launching and Analyzing Implementation Runs The Project Summary window shows the settings and the results of the active run. 5. In the Project Summary window click the Post-Implementation tab at the bottom of the Utilization section. The implementation utilization is displayed as a bar graph, as shown in the figure below. Note the LUT Utilization is 53%. Figure 10: Project Summary Window 6. In the Design Runs window, right click the impl_3 run and select Make Active from the popup menu. 7. In the Project Summary window, click the Post-Implementation tab at the bottom of the Utilization section. The implementation utilization is displayed as a bar graph. Note that the LUT Utilization is 51%. The Area_Explore strategy resulted in lower utilization, as expected. Implementation 13

14 Step 4: Analyzing Implementation Runs Using Modified Timing Constraints 8. Compare the Elapsed Time for each run in the Design Runs window. Note that the run compiled with the Flow_RuntimeOptimized strategy compiled the fastest. 9. Compare the Worst Negative Slack (WNS) for each run in the Design Runs window. All runs meet the timing constraints. Step 4: Analyzing Implementation Runs Using Modified Timing Constraints To see the impact of the Performance_Explore strategy on meeting timing, you will change the timing constraints of the design to make timing closure more challenging. 1. In the Sources window, double-click the top_full.xdc file in the constrs_2 constraint set. As shown in the figure below, top_full.xdc opens in the Vivado text editor with the create_clock command highlighted in the toolbar. Figure 11: Sources Window 2. Change the clock period constraint for clock sysclk from 10 ns to 6.5 ns. Figure 12: top_full.xdc File Implementation 14

15 3. Save the changes by selecting File > Save File. Step 4: Analyzing Implementation Runs Using Modified Timing Constraints Note: Changing the active constraints changes the run status for all runs from Complete to Out-of-date. 4. Select all runs in the Design Runs window, and click the Reset Selected Runs icon. 5. At the Reset Runs prompt (shown in the figure below), enable the checkbox Delete the generated files in the working directory and click the Reset button. The status of all runs changes from Out-of-date to Not started. Figure 13: Reset Runs 6. In the Design Runs window, select all the implementation runs. 7. Click the Launch Selected Runs icon. The Launch Selected Runs window opens. 8. Select Launch runs on local host and Number of jobs: 2 in the Launch Selected Runs window (shown in the figure below) and click OK. Figure 14: Launch Selected Runs Window Implementation 15

16 Step 4: Analyzing Implementation Runs Using Modified Timing Constraints Note: When the first implementation run finishes, you might see a prompt to Open Implemented Design, Generate Bitstream, or View reports (see figure below). Just click Cancel. Figure 15: Implementation Completed Prompt Two runs launch simultaneously; the others are queued. Wait until all the runs have finished to analyze the results. Implementation 16

17 Step 4: Analyzing Implementation Runs Using Modified Timing Constraints Figure 16: Project Summary Window 9. In the Design Runs window, right click the impl_2 run and select Make Active from the popup menu. Notice that only the run impl_2 compiled with the Performance_Explore strategy has a positive WNS. 10. Compare the Elapsed Time for each run in the Design Runs window. You will notice that the run compiled with the Performance_Explore took almost twice as long as the other runs to complete. This is because the Performance_Explore strategy uses multiple algorithms for optimization, placement, and routing to get potentially better results. RECOMMENDED: Reserve the Performance_Explore strategy for designs that have challenging timing constraints. When timing is easily met, the Performance_Explore strategy might increase compile times for no timing improvement benefit. 11. If you plan to continue to Lab #2, Using Incremental Compile, keep the Vivado IDE open. If you do not plan to continue, close the IDE. Implementation 17

18 Conclusion Conclusion In this lab you have: Learned how to create multiple runs with different implementation strategies Closed timing on a timing-critical design using the Performance_Explore strategy Implementation 18

19 Lab 2 Lab #2: Using Incremental Compile Introduction In this lab, you will learn how to use the incremental compile flow to speed up place and route runtime for designs already implemented that require small changes and a re-compile. You will use the BFT HDL example design that is included in the Vivado IDE. Step 1: Opening the Example Project 1. Start by loading Vivado IDE by doing one of the following: Launch the Vivado IDE from the icon on the Windows desktop Type vivado from a command terminal. 2. From the Getting Started page, click Open Example Project and select the BFT Core design, as shown in the figure below. Figure 17: Open Example Design Implementation 19

20 Step 1: Opening the Example Project 3. A dialog box appears, entitled Project is Read-Only. Select Save Project As to specify a project name and location. Figure 18: Save Project As The Vivado IDE displays project information in the Project Summary Window, shown in the figure below. Figure 19: Project Summary Window Implementation 20

21 Step 2: Compiling the Reference Design Step 2: Compiling the Reference Design 1. From the main menu, select Flow > Run Implementation. The Missing Synthesis Results dialog box opens, as shown in the figure below. The dialog box appears because you are trying to run implementation without an available synthesis netlist. 2. Click OK to launch synthesis first. Implementation starts automatically when synthesis completes. Figure 20: Missing Synthesis Results Dialog Box 3. After implementation finishes, the Implementation Complete dialog box opens. Click Cancel to dismiss the dialog box. Figure 21: Implementation Completed Dialog Box Implementation 21

22 Step 2: Compiling the Reference Design As shown in the figure below, the Design Runs window now shows the status of the current implementation run as Complete. Figure 22: Design Runs Window Reference Design During Implementation, Vivado saves intermediate results as checkpoints in the implementation runs directory. You will use the implementation results from the current run as the reference for the incremental compile. 4. In the Design Runs window, right click on impl_1 and select Open Run Directory from the popup menu. This opens the run directory in a file browser, and you can see the various checkpoints that have been saved. The location of the current implementation run directory is also a property of the run. 5. Check the location of the current implementation run directory in the Tcl Console by typing: get_property DIRECTORY [current_run] This returns the path to the current run directory that contains the reference checkpoint. Implementation 22

23 Step 3: Create a New Synthesis and Implementation Run Step 3: Create a New Synthesis and Implementation Run 1. From the main menu, select Flow > Create Runs. Figure 23: Create New Runs Wizard 2. In the first page of the wizard, select Both and click Next. The Configure Synthesis Runs window opens, as shown in the figure below. Figure 24: Configure Synthesis Runs Window 3. Accept the default options by clicking Next. The Configure Implementation Runs window opens, as shown in the figure below. Implementation 23

24 Step 3: Create a New Synthesis and Implementation Run Figure 25: Configure Implementation Runs Window 4. Accept the default options by clicking Next. The Launch Options window opens, as shown in the figure below. 5. Select Do not launch now and click Next. Figure 26: Launch Options Window Implementation 24

25 Step 3: Create a New Synthesis and Implementation Run 6. In the Create New Runs Summary window, shown in the figure below, click Finish to create the new synthesis and implementation runs. Figure 27: Create New Runs Summary Window 7. In the Design Runs window, right click the new implementation run impl_2 and select Make Active from the popup menu. The Design Runs window shows the newly created runs in bold below the Reference Design runs, indicating that they make up the active run. Figure 28: Design Runs Window Implementation 25

26 Step 4: Make Incremental RTL Design Changes Step 4: Make Incremental RTL Design Changes 1. Double-click the top-level VHDL file bft.vhdl in the Sources window (shown below), to open the file in the Vivado IDE text editor. Figure 29: Sources Window 2. Go to line 45 of the bft.vhdl file and change the error port from an out to a buffer, as follows: Figure 30: Line 45 Change to bft.vhdl File Implementation 26

27 Step 4: Make Incremental RTL Design Changes 3. Go to line 331 of the bft.vhdl file and modify the VHDL code, as described by the figures below. The first figure shows the code you start with. The second figure below shows how the code should look after you make modifications. Figure 31: VHDL Code to Modify 4. Click File > Save File to save the changes. Figure 32: Modified VHDL Code Note: As you can see in the figure below, changing the active constraints also changes the run status for the reference run impl_1 from Complete to Out-of-date. Figure 33: Design Runs Window Status Change Implementation 27

28 Step 5: Setting the Incremental Compile Checkpoint Step 5: Setting the Incremental Compile Checkpoint 1. In the Design Runs window, right click the new implementation run impl_2 and select Set Incremental Compile from the popup menu. The Set Incremental Compile Window opens, as shown in the figure below. You are going to select the routed checkpoint from implementation run impl_1, which you previously compiled in Step 2, as the incremental compile checkpoint. 2. Click the icon in the Set Incremental Compile flow and browse to the./project_bft_hdl.runs/impl_1 directory to select bft_routed.dcp as the incremental compile checkpoint. 3. Click OK. Figure 34: Set Incremental Compile Window The INCREMENTAL_CHECKPOINT property of the current run is now set to the bft_routed.dcp checkpoint, enabling incremental compile for the current run. Select the Properties tab, as shown highlighted in the figure below, to see the new incremental compile checkpoint. Figure 35: Implementation Run Properties Window Implementation 28

29 4. Check the incremental checkpoint location in the Tcl Console by typing: get_property INCREMENTAL_CHECKPOINT [current_run] This returns the full path to the bft_routed.dcp checkpoint. Step 6: Compiling Incrementally TIP: To disable incremental compile for the current run, do one of the following: Clear the INCREMENTAL_CHECKPOINT property through the Set Incremental Compile window or the Implementation Run Properties window. Execute the following command in the Tcl Console: reset_property INCREMENTAL_CHECKPOINT [current_run]. Step 6: Compiling Incrementally 1. From the main menu, select Flow >Run Implementation. This runs synthesis and implementation on the current run. Note: When the first implementation run finishes, you might be prompted to Open Implemented Design, Generate Bitstream, or View reports (see figure below). Just hit Cancel. Figure 36: Implementation Completed Prompt Implementation 29

30 2. From the Flow Navigator, select Open Implemented Design and click OK. Step 6: Compiling Incrementally As shown in the figure below, the Design Runs window shows that the elapsed time for implementation run impl_2 is lower than for impl_1 because of the incremental compile flow. Note: You will notice greater time savings for designs with longer run times. Figure 37: Design Runs Window Summary 3. Select the Reports tab in the Results Window Area and double-click the Incremental Reuse Report in the Place Design section, as highlighted in the figure below. Figure 38: Reports Window Implementation 30

31 Step 6: Compiling Incrementally The Incremental Reuse Report (see the figure below) shows the percentage of reused Cells, Ports and Nets. The higher the percentage, the more effective the reuse of placement and routing from the incremental checkpoint. Figure 39: Incremental Reuse Report Implementation 31

32 Conclusion 4. Open the log file to view an Incremental Routing Summary: a. Select the Log tab in the Results Window Area. b. Scroll to the Incremental Routing Reuse Summary. Figure 40: Incremental Routing Reuse Summary The Incremental Routing Summary displays reuse statistics according to net fanout distribution. Fully reused indicates that the entire net s routing is reused from the reference design. Partially reused indicates that some of the net s routing from the reference design is reused. Some segments are re-routed due to changed cells, changed cell placements, or both. Non reused indicates that the net in the current design was not matched in the reference design. Conclusion In this lab you have: Learned how to run Incremental Compile using a checkpoint from a previously compiled run Examined the similarity between a reference design checkpoint and the current run by examining the Incremental Reuse Report Implementation 32

33 Lab 3 Lab #3: Manual Routing and Directed Routing Introduction In this lab, you will learn how to use the Vivado IDE to assign routing to nets to precisely control the timing for a critical portion of the design. You will use the BFT HDL example design that is included in the Vivado IDE. To illustrate the manual routing feature, you will precisely control the skew within the output bus, wboutputdata, of the design. Step 1: Opening the Example Project 1. Load the Vivado IDE by doing one of the following: Launch the Vivado IDE from the icon on the Windows desktop Type vivado from a command terminal. 2. From the Getting Started page, click Open Example Project and select the BFT Core design. Figure 41: Open Example Design 3. To protect the original example design, and to avoid overwriting it, save the project to a new location. a. Select File > Save Project As and specify a project name and location, as shown in the example figure, below. Implementation 33

34 Step 1: Opening the Example Project Figure 42: Save Project As Dialog Box The project is saved to the specified location, as shown below. Figure 43: Project Summary Window Implementation 34

35 Step 2: Compiling the Reference Design Step 2: Compiling the Reference Design Run Synthesis and Implementation 1. Do one of the following: From the main menu, select Flow > Run Implementation. In the Flow Navigator, click Run Implementation. In the Design Runs window, select the implementation run impl_1 and select Launch Runs from the popup menu. The Missing Synthesis Results dialog box (shown below) opens because you are trying to run implementation without an available synthesis netlist. 2. Click OK to launch synthesis first. Figure 44: Missing Synthesis Results Dialog Box Implementation automatically starts when synthesis completes. (It might take a few minutes for the processes to complete.) After implementation finishes, the Implementation Complete dialog box (shown below) opens. Figure 45: Implementation Completed Dialog Box Implementation 35

36 Step 2: Compiling the Reference Design Open Device View and Display Routing Resources 1. In the Implementation Completed dialog box, select Open Implemented Design and click OK. This opens the Device view of the design, as shown in the figure below. Figure 46: Device View 3. Ensure the Routing Resources button is highlighted. This displays the routing resources used by the design in green. Important! The design has an output bus wboutputdata that feeds external logic. The goal is to precisely control the skew within the members of this output bus. Implementation 36

37 Step 2: Compiling the Reference Design Analyze Output Bus Members Timing You can use the Report Datasheet command to analyze the current timing of the members of the output bus wboutputdata. Using the Report Datasheet command allows you to analyze the timing of a group of ports with respect to a reference port. 1. To open the Report Datasheet dialog box, shown in the figure below, select Tools > Timing > Report Datasheet. 2. Select the Groups tab in the dialog box. a. Enter [get_ports {wboutputdata[0]}] in the Reference field. b. Enter [get_ports {wboutputdata[*]}] in the Ports field. c. Click OK. This adds a Max/Min Delays in the Groups section for output bus wboutputdata in the Datasheet timing report window. Figure 47: Report Datasheet Dialog Box Implementation 37

38 Step 2: Compiling the Reference Design 3. To display the group you have just created, maximize the Timing - Datasheet - timing_1 window (shown below) and select the Max/Min Delays for Groups Clocked by wbclk - wboutputdata[0] section. Note: As you can see from the report, the skew across the output bus wboutputdata varies by as much as 536 ps. The goal is to minimize the skew across the bus to less than 100 ps. Figure 48: Timing Datasheet timing_1 Window 4. To analyze the placement and routing of the output bus wboutputdata: minimize the Timing Datasheet timing_1 window so you can simultaneously see the Device view and the Timing - Datasheet window. Note that the output wboutputdata[0] has one of the longest delays. 5. Click the hyperlink for the setup time of the source wboutputdata[0]. This highlights the path in the Device view window that is currently open. 6. Make sure Autofit Selection is highlighted in the Device view so you can see the entire path, as shown in the figure below. Implementation 38

39 Step 2: Compiling the Reference Design Figure 49: Device View with Autofit Selection Highlighted 8. Right click the highlighted path in the Device view and select Schematic from the context menu. This displays the schematic for the output path. (See the figure below.) Note: From the schematic, you can see that the output is directly driven from a register through an OBUF. Therefore, if you can control the placement of the register with respect to the output pin, and control the routing between register and output, you can minimize skew between the members of the output bus. Implementation 39

40 Step 2: Compiling the Reference Design 9. Switch back to the Device view. Figure 50: Schematic Displaying the Output Path 10. To better visualize the placement of the registers and outputs, you can use the mark_objects command to mark them in the Device view. Click the Tcl Console tab in the Results Window and type the following commands: mark_objects -color blue [get_ports wboutputdata[*]] mark_objects -color red [get_cells wboutputdata_reg[*]] Note: When you perform the actions above, a blue diamond marker appears on the outputs and a red diamond marker appears on the registers feeding the outputs. Zooming out on the Device view displays a picture similar to the one shown below. The outputs marked in blue are spread out along two banks on the left side starting with wboutputdata[0] (on the bottom) and ending with wboutputdata[31] (at the top), while the output registers marked in red are clustered close together on the right. Implementation 40

41 Step 2: Compiling the Reference Design Figure 51: Display Resulting from Use of mark_objects Tcl Command 11. To look at the routing from the registers wboutputdata_reg[*] to the outputs wboutputdata[*], you can use the highlight_objects Tcl command to highlight the nets. highlight_objects -color magenta [get_nets -of [get_pins -of [get_cells wboutputdata_reg[*]] -filter DIRECTION==OUT]] This highlights all the nets of the pins that are outputs of the wboutputdata_reg[*] registers as shown in the figure below. In the Device view (which should look similar to the figure below), you can see that there are various routing distances between the output registers and the outputs of the bus wboutputdata. If the output registers were placed in the slices next to output ports instead, you could eliminate a majority of the variability in the clock-to-out delay of wboutputdata. The following steps explain how best to do this. Implementation 41

42 Step 2: Compiling the Reference Design Figure 52: Display Resulting from Use of highlight_objects Tcl Command Improve wboutputdata Bus Timing through Placement Recommended: Use a series of Tcl commands to place the output registers in the slices next to the wboutputdata bus outputs. 1. Select the Tcl Console Tab in the results window. 2. Un-place any cells currently assigned to the slices SLICE_X0Y36 to SLICE_X0Y67 with the command: for {set i 0} {$i<32} {incr i} {unplace_cell [get_cells -of [get_sites SLICE_X0Y[expr 36 + $i]]] } Note: If there are no cells placed within the slices, you will see a warning message, which you can safely ignore. 3. Place the output registers wboutputdata_reg[31:0] in the above slice locations with the command: for {set i 0} {$i<32} {incr i} {place_cell wboutputdata_reg[$i] SLICE_X0Y[expr 36 + $i]/aff} 4. Place the remaining cells unplaced in step 2, above, with the command: place_design Note: The Vivado placer works incrementally on a partially placed design. 5. Un-route all nets terminating and originating at output registers wboutputdata_reg[31:0] with the command: Implementation 42

43 route_design unroute nets [get_nets of [get_cells wboutputdata_reg[*]] ] 6. Route the nets of all the cells with new placement using the command: route_design Step 2: Compiling the Reference Design Note: The Vivado router works incrementally on a partially routed design. 7. Analyze the route status of the current design to ensure that there are no routing conflicts: report_route_status. After executing these commands, the Device view displays the results, as shown in the following figure. You can see that all output registers are now equidistant from their associated outputs, and the routing path is very similar for all the nets from output register to output. This results in clock-to-out times that are closely matched between the outputs. Figure 53: Device View Showing Improved Placement of Outputs and Output Registers Implementation 43

44 Step 2: Compiling the Reference Design Re-Analyze the Updated Timing. 1. Select the Timing tab in the Results Window Area. Notice that the information message on the top of the datasheet report window indicates that the report is out of date because timing data has been modified. 2. Click Rerun to update the report with the latest timing information. 3. Select the Max/Min Delays for Groups Clocked by wbclk - wboutputdata[0] section to display the timing info for the wboutputdata bus (shown in the figure below). Figure 54: Timing Datasheet Showing Clock Skew The skew within the lower bits 0-13 is closely matched, as is the skew within the upper bits However, between the upper and lower bits the skew is around 200 ps. This skew is a result of the output registers spanning two clock regions, which introduces clock network skew. There are different ways to eliminate this skew. For example: Using a BUFMR/BUFR combination instead of a BUFG to clock the output register would reduce the skew. Manual routing could be employed to add delay from the output register clocked by the BUFG to the output pin for the upper bits to further reduce the clock-to-out variability within the bus. Implementation 44

45 For this tutorial, you will use the manual routing method for eliminating skew. Reduce the Clock Skew with Manual Routing Step 2: Compiling the Reference Design 1. Select net n_0_wboutputdata_reg[14], the first net of the upper section of the bus. You can use a TCL command to efficiently select the net. In the Tcl Console type: select_objects [get_nets n_0_wboutputdata_reg[14]] 2. Right click the net and select Unroute from the context menu. Click Yes in the Confirm Unroute pop-up window. The Device view shows the net is no longer routed and appears as a flyline between the register and the output. 3. Right click on the net and select Enter Assign Routing Mode from the context menu, as shown in the figure below. Figure 55: Enter Assign Routing Mode Option in Device View 4. The Target Load Cell Pin window pops-up (see figure below). This window allows you to select the loads to which you want to route. Selecting one of the load cell pins and clicking OK would allow you to route from the target load back to the source. You are going to let the router route the final section of the net to the output port. Click No Load. Implementation 45

46 Step 2: Compiling the Reference Design Figure 56: Target Load Cell Pin Window This puts the Vivado IDE into Assign Routing Mode, and a new Routing Assignment section is displayed on the right side of the Device view. The Routing Assignment section is divided into: An upper portion, showing an ordered list of assigned interconnect nodes A lower portion, showing a list of neighbor PIPs/nodes of the selected assigned node for the next assigned route choice. In the figure below, the Assigned Nodes section and the Neighbor Nodes section are shown highlighted in red. Two nodes are already assigned. The nodes are displayed in orange in the Device view because a node is automatically assigned if it is the only neighbor of a selected node. In this example, nodes CLBLL_LL_AQ and CLBLL_LOGIC_OUTS4 are already assigned because they are the only neighbor nodes available to their source. The neighbor nodes of the selected assigned node are displayed as dashed white lines in the Device view. Implementation 46

47 Step 2: Compiling the Reference Design Figure 57: Device View Showing Assigned Nodes and Neighbor Nodes 5. To add additional delay to compensate for the clock skew, you must select a node that provides a slight detour over the previous, direct route chosen by the router. a. Instead of the WW2BEG0 node, which provides a more direct route back to the output pad, select NE2BEG0, which provides enough of a detour to compensate for the additional delay to the lower-order output bits. b. Assign the route to node NE2BEG0 by double clicking the node in the Neighbor Nodes section of the Routing Assignment window. The node NE2BEG0 appears in the Assigned Nodes section, and the next set of possible route nodes are shown in the Neighbor Nodes section. c. Repeat the node assignments for WR1BEG1, WR1BEG2, SW2BEG1 in that order. In the figure below, the nodes that have been assigned are shown in orange. TIPS In case you assigned the wrong node, you can select the node from the Assigned Nodes list, right click, and select Remove on the context menu You can turn off the Auto Fit Selection in the Device view if you would like to stay at the same zoom level. Implementation 47

48 Step 2: Compiling the Reference Design Figure 58: Device View Showing New Routing 6. Now that you have selected the detour, you can assign the nodes and let the router route the rest of the net. a. Click Assign Routing at the bottom of the Routing Assignment window. b. Make sure Fix Routing is checked and click OK. This assigns all the nodes listed in the Assign Routing window (shown in the figure below) as route segments to net n_0_wboutputdata_reg[14]. Implementation 48

49 Step 2: Compiling the Reference Design Figure 59: Assign Routing Window 7. Select the Tcl Console tab in the results window. The GUI commands that assigned the routing have been mirrored in the Tcl console, as shown in the figure below. Those commands are: set_property is_bel_fixed 1 [get_cells {wboutputdata_reg[14] }] set_property is_loc_fixed 1 [get_cells {wboutputdata_reg[14] }] set_property fixed_route {{ CLBLL_LL_AQ CLBLL_LOGIC_OUTS4 NE2BEG0 WR1BEG1 WR1BEG2 SW2BEG1 }} [get_nets {n_0_wboutputdata_reg[14]}] The DIrected RouTe (DIRT) string used for the fixed_route property of net n_0_wboutputdata_reg[14] uses a relative format, and the route is realized based on placement of the driver. This makes it easy to apply the same property to other nets later and use the same fixed route. Implementation 49

50 Step 2: Compiling the Reference Design Figure 60: Tcl Console Showing Routing Commands 8. Route the rest of the net to the output by typing the following command in the Tcl Console: route_design -nets [get_nets n_0_wboutputdata_reg[14]] The Device view shows the routed net, and fixed routing is represented as a dashed line, as shown in the figure below. Figure 61: Device View Showing Routed Net and Fixed Routing 9. The net n_0_wboutputdata_reg[14] is now routed with the detour. To examine the timing for the net with respect to the lower order bits that showed the additional delay due to the clock skew, select the Timing tab in the Results Window Area. Notice the information message on the top of the datasheet report window that indicates that the report is out of date because timing data has been modified. 10. Click Rerun to update the report with the latest timing information. 11. Select the Max/Min Delays for Groups Clocked by wbclk - wboutputdata[0] section to display the timing info for the wboutputdata bus (see the figure below). The skew within the lower bits wboutputdata[13:0] and wboutputdata[14] is now closely Implementation 50

51 Step 2: Compiling the Reference Design matched (within 38 ps of reference pin wboutputdata[0]). You can now apply the same fixed route to nets n_0_wboutputdata_reg[31:15] to bring the output delays in line with the other members of the wboutputdata bus. Figure 62: Timing Datasheet Display for wboutputdata Bus 12. To apply the same fixed route used for net n_0_wboutputdata_reg[14] to nets n_0_wboutputdata_reg[31:15], you can use three simple for loops to accomplish the tasks described below: a. Select the Tcl Console Tab in the results window. b. Un-route the nets n_0_wboutputdata_reg[31:15]using: for {set i 15} {$i<32} {incr i} {route_design -unroute -nets [get_nets n_0_wboutputdata_reg[$i]]} Implementation 51

52 Step 2: Compiling the Reference Design c. Apply the fixed_route property of net n_0_wboutputdata_reg[14] to the nets using: for {set i 15} {$i<32} {incr i} {set_property fixed_route [get_property fixed_route [get_nets n_0_wboutputdata_reg[14]]] [get_nets n_0_wboutputdata_reg[$i]] } d. Route the nets to complete the route from the fixed route to the output using: for {set i 15} {$i<32} {incr i} {route_design -nets [get_nets n_0_wboutputdata_reg[$i]]} e. Analyze the route status of the current design to ensure there are no routing conflicts: report_route_status. 13. Review the results in the Device view (see the figure below). All nets from the output registers to the output pins for the upper bits of the output bus wboutputdata have identical fixed routing sections (shown as dashed lines). You do not need to fix the LOC and the BEL for the output registers because that was achieved by the place_cell command in an earlier step. Figure 63: Device View after Applying Fixed Route for Nets 14. Having routed all the upper bit nets n_0_wboutputdata_reg[31:14] with the detour, you can now examine the timing of output bus wboutputdata again. Select the Timing tab in the Results Window Area. Notice the information message on the top of the datasheet report window indicating that the report is out of date because timing data has been modified. 15. Click Rerun to update the report with the latest timing information. Implementation 52

53 Conclusion 16. Select the Max/Min Delays for Groups Clocked by wbclk - wboutputdata[0] section to display the timing info for the wboutputdata bus. As shown in the figure below, the clockto-out timing within all bits of output bus wboutputdata is now closely matched to within 83 ps. Figure 64: Timing Datasheet Showing Clock-to-Out Timing Data for wboutputdata Bus 17. Save the constraints to write them to the target XDC, so that they are applied every time you compile the design. Select File > Save Constraints to save the placement and routing constraints to the target constraint file bft_full.xdc in the active constraint set constrs_2. Conclusion In this lab you: Learned how to use the Assign Manual Routing Mode in the Vivado IDE to precisely control the routing of a net. Applied the fixed_route property to nets to control the routing of the critical portion of the net. Implementation 53