Vivado Design Suite User Guide:

Transcription

1 Vivado Design Suite User Guide: Programming and Debugging

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 2012 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 07/25/ Initial Xilinx release. 10/16/ Update to Bitstream settings. Vivado Programming and Debugging 2

3 Table of Contents Revision History Chapter 1: Introduction Getting Started Chapter 2: Programming the Device Introduction Generating the Bitstream Changing the Bitstream File Format Settings Changing Device Configuration Bitstream Settings Programming the FPGA Device Launching impact Using a Vivado Hardware Session to Program an FPGA Device Chapter 3: Debugging the Design Introduction RTL-level Design Simulation Post-Implemented Design Simulation In-System Debugging Chapter 4: In-System Debugging Flows Introduction Probing the Design for In-System Debugging Using the Netlist Insertion Debug Probing Flow HDL Instantiation Debug Probing Flow Overview Using the HDL Instantiation Debug Probing Flow Implementing the Design Containing the Debug Cores Chapter 5: Debugging the Design in Hardware Introduction Launching ChipScope Pro Analyzer to Debug the Design Using Vivado Logic Analyzer to Debug the Design Connecting to the Hardware Target and Programming the FPGA Device Vivado Programming and Debugging 3

4 Setting up the ILA Core to Take a Measurement Setting the ILA Core Trigger Condition Setting the ILA Core Trigger Position Writing ILA Probes Information Reading ILA Probes Information Viewing ILA Probes Setting Up the ILA Probe Trigger Compare Values ILA Probe Compare Value Settings Running or Arming the ILA Core Trigger Stopping the ILA Core Trigger Viewing the ILA Core State Viewing Captured Data from the ILA Core in the Waveform Viewer Saving and Restoring Captured Data from the ILA Core Using Vivado Logic Analyzer in a Lab Environment Using Vivado Logic Analyzer and ChipScope Pro Analyzer Simultaneously Description of Hardware Session Tcl Objects and Commands Using Hardware Session Tcl Commands Chapter 6: Viewing ILA Probe Data Using Waveform Viewer Introduction Waveform Viewer Features and Limitations Waveform Viewer Configuration Signals and Buses ILA Probes in Waveform Configuration Customizing the Wave Configuration Renaming Objects About Radixes and Analog Waveforms Zoom Gestures Appendix A: Device Configuration Bitstream Settings Scope Appendix B: Additional Resources Xilinx Resources Solution Centers References Vivado Programming and Debugging 4

5 Chapter 1 Introduction Getting Started After successfully implementing your design, the next step is to run it in hardware by programming the FPGA device and debugging the design in-system. All of the necessary commands to perform programming of FPGA devices and in-system debugging of the design are in the Program and Debug section of the Flow Navigator window in the Vivado TM Integrated Design Environment (IDE) (see Figure 1-1) X-Ref Target - Figure 1-1 Figure 1-1: Program and Debug section of the Flow Navigator panel Vivado Programming and Debugging 5

6 Chapter 2 Programming the Device Introduction The hardware programming phase is broken into two steps: 1. Generating the bitstream data programming file from the implemented design. 2. Connecting to hardware and downloading the programming file to the target FPGA device. Generating the Bitstream Before generating the bitstream data file, it is important to review the bitstream settings to make sure they are correct for your design. There are two types of bitstream settings in Vivado IDE: 1. Bitstream file format settings. 2. Device configuration settings. The Bitstream Settings button in the Flow Navigator and the Flow > Bitstream Settings menu selection opens the Bitstream section in the Project Settings popup window (see Figure 2-1). Once the bitstream settings are correct, the bitstream data file can be generated using the write_bistream Tcl command or by using the Generate Bitstream button in the Flow Navigator. Vivado Programming and Debugging 6

7 Changing the Bitstream File Format Settings X-Ref Target - Figure 2-1 Figure 2-1: Bitstream settings panel Changing the Bitstream File Format Settings By default, the write_bitstream Tcl command will generate a binary bitstream (.bit) file only. You can optionally change the file format(s) written out by the write_bitstream Tcl command by using the following command switches: -raw_bitfile: (Optional) Causes write_bitstream to write a raw bit file (.rbt) which contains the same information as the binary bitstream file, but is in ASCII format. The output file will be named filename.rbt -mask_file: (Optional) Write a mask file (.msk), which has mask data where the configuration data is in the bitstream file. This file determines which bits in the bitstream should be compared to readback data for verification purposes. If a mask bit is 0, that bit should be verified against the bitstream data. If a mask bit is 1, that bit should not be verified. The output file will be named file.msk. Vivado Programming and Debugging 7

8 Changing Device Configuration Bitstream Settings -no_binary_bitfile: (Optional) Do not write the binary bitstream file (.bit). Use this command when you want to generate the ASCII bitstream or mask file, or to generate a bitstream report, without generating the binary bitstream file. -logic_location_file: (Optional) Creates an ASCII logic location file (.ll) that shows the bitstream position of latches, flip-flops, LUTs, Block RAMs, and I/O block inputs and outputs. Bits are referenced by frame and bit number in the location file to help you observe the contents of FPGA registers. -bin_file: (Optional) Creates a binary file (.bin) containing only device programming data, without the header information found in the standard bitstream file (.bit). -reference_bitfile <arg>: (Optional) Read a reference bitstream file, and output an incremental bitstream file containing only the differences from the specified reference file. This partial bitstream file can be used for incrementally programming an existing device with an updated design. Changing Device Configuration Bitstream Settings The most common configuration settings that you can change fall into the device configuration settings category. These settings are properties on the device model and you change them by using the set_property command in an XDC file. For instance, here is an example on how to change the start-up DONE cycle property: set_property BITSTREAM.STARTUP.DONE_CYCLE 4 [current_design] Additional examples and templates are provided in the Vivado Templates. Appendix A, Device Configuration Bitstream Settings describes all of the device configuration settings. Programming the FPGA Device The next step after generating the bitstream data programming file is to download it into the target FPGA device. The Vivado tool offers two different ways to do this: Launch the impact device programmer tool using the Launch impact button in the Flow Navigator or Flow > Launch impact menu option. Open a hardware session to use the native in-system device programming capabilities that are built into the Vivado IDE. Vivado Programming and Debugging 8

9 Launching impact Launching impact The impact tool lets you perform device configuration and file generation. Device Configuration lets you directly configure Xilinx FPGAs and PROMs with the JTAG download cables (Xilinx Parallel Cable IV, Xilinx Platform Cable USB, Xilinx Platform Cable USB II, or Digilent JTAG cables). Operating in Boundary-Scan mode, impact can configure or program Xilinx FPGAs, CPLDs, and PROMs. File generation enables you to create the following programming file types: System ACE CF, PROM, SVF, STAPL, and XSVF files. impact also lets you: Readback and verify design configuration data. Debug configuration problems. Execute SVF and XSVF files. You can launch the impact software tool directly from the Vivado IDE on any implemented design on which the Generate Bitstream command has been run. To invoke impact, in the Flow Navigator, select Launch impact. The BIT bitstream file is passed automatically to impact when launched from the Vivado tool. For more information on using impact, see the impact Help. Using a Vivado Hardware Session to Program an FPGA Device The Vivado IDE tool includes functionality that allows you to connect to hardware containing one or more FPGA devices in order to program and interact with those FPGA devices. Connecting to hardware can be done from either the Vivado IDE graphical user interface or by using Tcl commands. In either case, the steps to connect to hardware and program the target FPGA device are the same: 1. Open a hardware session. 2. Open a hardware target that is managed by a hardware server running on a host computer. 3. Associate the bitstream data programming file with the appropriate FPGA device. 4. Program or download the programming file into the hardware device. Vivado Programming and Debugging 9

10 Using a Vivado Hardware Session to Program an FPGA Device Opening a Hardware Session Opening a hardware session is the first step in programming and/or debugging your design in hardware. To open a hardware session, do one of the following: Click on the Open Hardware Session button in the Program and Debug section of the Flow Navigator. Select the Flow > Open Hardware Session menu option. Opening Hardware Target Connections The next step in opening a hardware target (for instance, a hardware board containing a JTAG chain of one or more FPGA devices) is connecting to the hardware server (also called the CSE server) that is managing the connection to the hardware target. You can do this one of three ways: Use the Open New Hardware Target selection in the Hardware view to use a wizard-based flow to open a new connection to a hardware target. Use the Open Recent Hardware Target selection in the Hardware view to re-open a connection to a previously connected hardware target. Use Tcl commands to open a connection to a hardware target. Opening a New Hardware Target The Open New Hardware Target wizard provides an interactive way for you to connect to a hardware server and target. The wizard is a three-step process: 1. Specify or select the host name and port of the CSE server (also called hardware server or cse_server) that is managing the hardware targets on the machine to which the target board is connected (see Figure 2-2). Note: If you use localhost as the host name, a cse_server process will automatically be started on the machine on which you are running the Vivado tool and will be used in the subsequent panels of the wizard. Vivado Programming and Debugging 10

11 Using a Vivado Hardware Session to Program an FPGA Device X-Ref Target - Figure 2-2 Figure 2-2: Specifying the CSE Server Name 2. Select the appropriate hardware target from the list of targets that are managed by the hardware server. Note that when you select a target, you will see the various hardware devices that are available on that hardware target (see Figure 2-3). Vivado Programming and Debugging 11

12 Using a Vivado Hardware Session to Program an FPGA Device X-Ref Target - Figure 2-3 Figure 2-3: Selecting the Hardware Target 3. Set the properties of the hardware target, such as the frequency of the TCK clock pin, etc. Note that each type of hardware target may have different properties. Refer to the documentation of each hardware target for more information about these properties. Opening a Recent Hardware Target The Open New Hardware Target wizard is also what populates the list of previously connected hardware targets to be used by the Open Recent Hardware Target selection. Instead of connecting to a hardware target by going through the wizard, you can also re-open a connection to a previously connected hardware target by selecting the Open Recent Hardware Target link in the Hardware window and selecting one of the recently connected hardware server/target combinations in the list. Vivado Programming and Debugging 12

13 Using a Vivado Hardware Session to Program an FPGA Device Opening a Hardware Target Using Tcl Commands You can also use Tcl commands to connect to a hardware server/target combination. For instance, to connect to the digilent_plugin target (serial number ) that is managed by the cse_server running on localhost:50001, use the following Tcl commands: connect_hw_server -host localhost -port current_hw_target [get_hw_targets */digilent_plugin/sn: ] open_hw_target Once you finish opening a connection to a hardware target, the Hardware window will be populated with the hardware server, hardware target, and various hardware devices for the open target (see Figure 2-4). X-Ref Target - Figure 2-4 Figure 2-4: Hardware View after Opening a Connection to the Hardware Target Associating a Programming File with the Hardware Device After connecting to the hardware target and before you program the FPGA device, you need to associate the bitstream data programming file with the device. Select the hardware device in the Hardware window and make sure the Programming file property in the Properties window is set to the appropriate bitstream data (.bit) file. Note: As a convenience, Vivado IDE automatically uses the.bit file for the current implemented design as the value for the Programming File property of the first matching device in the open hardware target. You can also use the set_property Tcl command to set the PROGRAM.FILE property of the hardware device: set_property PROGRAM.FILE {C:/design.bit} [lindex [get_hw_devices] 0] Vivado Programming and Debugging 13

14 Using a Vivado Hardware Session to Program an FPGA Device Programming the Hardware Device Once the programming file has been associated with the hardware device, you can program the hardware device using by right-clicking on the device in the Hardware view and selecting the Program Device menu option. You can also use the program_hw_device Tcl command. For instance, to program the first device in the JTAG chain, use the following Tcl command: program_hw_devices [lindex [get_hw_devices] 0] Once the progress dialog has indicated that the programming is 100% complete, you can check that the hardware device has been programmed successfully by examining the DONE status in the Hardware Device Properties view (see Figure 2-5). X-Ref Target - Figure 2-5 Figure 2-5: Checking the DONE status of an FPGA device You can also use the get_property Tcl command to check the DONE status. For instance, to check the DONE status of a Kintex -7 device that is the first device in the JTAG chain, use the following Tcl command: get_property REGISTER.IR.BIT5_DONE [lindex [get_hw_devices] 0] If you use another means to program the hardware device (for instance, a Flash device or external device programmer such as the impact tool), you can also refresh the status of a hardware device by right-clicking the Refresh Device menu option or by running the refresh_hw_device Tcl command. This will refresh the various properties for the device, including but not limited to the DONE status. Vivado Programming and Debugging 14

15 Using a Vivado Hardware Session to Program an FPGA Device Closing the Hardware Target You can close a hardware target by right-clicking on the hardware target in the Hardware window and selecting Close Target from the popup menu. You can also close the hardware target using a Tcl command. For instance, to close the xilinx_platformusb/usb21 target on the localhost server, use the following Tcl command: close_hw_target {localhost/xilinx_platformusb/usb21} Closing a Connection to the Hardware Server You can close a hardware server by right-clicking on the hardware server in the Hardware window and selecting Close Server from the popup menu. You can also close the hardware server using a Tcl command. For instance, to close the connection to the localhost server, use the following Tcl command: disconnect_hw_server localhost Vivado Programming and Debugging 15

16 Chapter 3 Debugging the Design Introduction Debugging an FPGA design is a multistep, iterative process. Like most complex problems, it is best to break the FPGA design debugging process down into smaller parts by focusing on getting smaller sections of the design working one at a time rather than trying to get the whole design to work at once. Iterating through the design flow by adding one module at a time and getting it to function properly in the context of the whole design is one example of a proven design and debug methodology. You can use this design and debug methodology in any combination of the following design flow stages: RTL-level design simulation Post-implemented design simulation In-system debugging RTL-level Design Simulation The design can be functionally debugged during the simulation verification process. Xilinx provides a full design simulation feature in the Vivado IDE. The Vivado design simulator can be used to perform RTL simulation of your design. The benefits of debugging your design in an RTL-level simulation environment include full visibility of the entire design and ability to quickly iterate through the design/debug cycle. The limitations of debugging your design using RTL-level simulation includes the difficulty of simulating larger designs in a reasonable amount of time in addition to the difficulty of accurately simulating the actual system environment. For more information about using the Vivado simulator, please refer to the Vivado Design Suite User Guide: Logic Simulation (UG937) [Ref 1]. Vivado Programming and Debugging 16

17 Post-Implemented Design Simulation Post-Implemented Design Simulation The Vivado simulator can also be used to simulate the post-implemented design. One of the benefits of debugging the post-implemented design using the Vivado simulator includes having access to a timing-accurate model for the design. The limitations of performing post-implemented design simulation include those mentioned in the previous section: long run-times and system model accuracy. In-System Debugging The Vivado IDE also includes a logic analysis feature that enables you to perform in-system debugging of the post-implemented design an FPGA device. The benefits for debugging your design in-system include debugging your timing-accurate, post-implemented design in the actual system environment at system speeds. The limitations of in-system debugging includes somewhat lower visibility of debug signals compared to using simulation models and potentially longer design/implementation/debug iterations, depending on the size and complexity of the design. In general, the Vivado tool provides several different ways to debug your design. You can use one or more of these methods to debug your design, depending on your needs. Chapter 4, In-System Debugging Flows will focus on the in-system logic debugging capabilities of the Vivado IDE. Vivado Programming and Debugging 17

18 Chapter 4 In-System Debugging Flows Introduction The Vivado tool provides many features to debug a design in-system in an actual hardware device. The in-system debugging flow has three distinct phases: 1. Probing phase: Identifying what signals in your design you want to probe and how you want to probe them. 2. Implementation phase: Implementing the design that includes the additional debug IP that is attached to the probed nets. 3. Analysis phase: Interacting with the debug IP contained in the design to debug and verify functional issues. This in-system debug flow is designed to work using the iterative design/debug flow described in the previous section. If you choose to use the in-system debugging flow, it is advisable to get a part of your design working in hardware as early in the design cycle as possible. The rest of this chapter describes the three phases of the in-system debugging flow and how to use the Vivado logic debug feature to get your design working in hardware as quickly as possible. Probing the Design for In-System Debugging The probing phase of the in-system debugging flow is split into two steps: 1. Identifying signals or nets that you want to probe 2. Deciding how you want to add debug core(s) to your design In many cases, the decision you make on what signals to probe or how to probe them can affect one another. It helps to start by deciding if you want to manually add the debug IP component instances to your design source code (called the HDL instantiation probing flow) or if you want the Vivado tool to automatically insert the debug cores into your post-synthesis netlist (called the netlist insertion probing flow). Table 4-1 describes some of the advantages and trade-offs of the different debugging approaches. Vivado Programming and Debugging 18

19 Using the Netlist Insertion Debug Probing Flow Table 4-1: Debugging Strategies Debugging Goal Identify debug signals in the HDL source code while retaining flexibility to enable/disable debugging later in the flow. Identify debug nets in synthesized design netlist without having to modify the HDL source code. Automated debug probing flow using Tcl commands. Explicitly attach signals in the HDL source to an ILA debug core instance. Recommended Debug Programming Flow Use mark_debug property to tag signals for debugging in HDL. Use the Set up Debug wizard to guide you through the Netlist Insertion probing flow. Use the Mark Debug right-click menu option to select nets for debugging in the synthesized design netlist. Use the Set up Debug wizard to guide you through the Netlist Insertion probing flow. Use set_property Tcl command to set the mark_debug property on debug nets. Use Netlist Insertion probing flow Tcl commands to create debug core(s) and connect to them to debug nets. Identify HDL signals for debugging. Use the HDL Instantiation probing flow to generate and instantiate an Integrated Logic Analyzer (ILA) core and connect it to the debug signals in the design. Using the Netlist Insertion Debug Probing Flow Insertion of debug cores in the Vivado tool is presented in a layered approach to address different needs of the diverse group of Vivado users: The highest level is a simple wizard that creates and configures Integrated Logic Analyzer (ILA) v2.0 cores automatically based on the selected set of nets to debug. The next level is the main Debug window allowing control over individual debug cores, ports and their properties. The Debug window can be displayed by selecting the Debug layout from the Layout Selector or the Layers menu, or can be opened directly using Window > Debug. The lowest level is the set of Tcl debug commands that you can enter manually or replay as a script. You can also use a combination of the modes to insert and customize debug cores. Marking HDL Signals for Debug You can identify signals for debugging at the HDL source level prior to synthesis by using the mark_debug constraint. Nets corresponding to signals marked for debug in HDL are automatically listed in the Debug window under the Unassigned Debug Nets view. The procedure for marking nets for debug depends on whether you are working with an RTL source-based project or a synthesized netlist-based project. For an RTL netlist-based project: Vivado Programming and Debugging 19

20 Using the Netlist Insertion Debug Probing Flow Using the Vivado synthesis feature you can optionally mark HDL signals for debug using the mark_debug constraint in VHDL and Verilog source files. The valid values for the mark_debug constraint are TRUE or FALSE. The Vivado synthesis feature does not support the SOFT value. Using Xilinx Synthesis Technology (XST) you can optionally mark nets for debug using the mark_debug constraint in VHDL and Verilog sources. In addition to the boolean string values of, TRUE or FALSE, a value of SOFT allows the software to optimize the specified net, if possible. For a synthesized netlist-based project: Using the Synopsys Synplify synthesis tool, you can optionally mark nets for debug using the mark_debug and syn_keep constraints in VHDL or Verilog, or using the mark_debug constraint alone in the Synopsys Design Constraints (SDC) file. Synplify does not support the SOFT value, as this behavior is controlled by the syn_keep attribute. Using the Mentor Graphics Precision synthesis tool, you can optionally mark nets for debug using the mark_debug constraint in VHDL or Verilog. The following subsections provide syntactical examples for Vivado synthesis, XST, Synplify, and Precision source files. Vivado Synthesis mark_debug Syntax Examples The following are examples of VHDL and Verilog syntax when using Vivado synthesis. VHDL Syntax Example attribute mark_debug : string; attribute mark_debug of char_fifo_dout: signal is "true"; Verilog Syntax Example (* mark_debug = "true" *) wire [7:0] char_fifo_dout; XST mark_debug Syntax Examples The following are examples of VHDL and Verilog syntax when using XST. VHDL Syntax Example attribute mark_debug : string; attribute mark_debug of char_fifo_dout: signal is "true"; Verilog Syntax Example (* mark_debug = "true" *) wire [7:0] char_fifo_dout; Vivado Programming and Debugging 20

21 Using the Netlist Insertion Debug Probing Flow Synplify mark_debug Syntax Examples The following are examples of Synplify syntax for VHDL, Verilog, and SDC. VHDL Syntax Example attribute syn_keep : boolean; attribute mark_debug : string; attribute syn_keep of char_fifo_dout: signal is true; attribute mark_debug of char_fifo_dout: signal is "true"; Verilog Syntax Example (* syn_keep = "true", mark_debug = "true" *) wire [7:0] char_fifo_dout; SDC Syntax Example define_attribute {n:char_fifo_din[*]} {mark_debug} {"true"} IMPORTANT: Net names in an SDC source must be prefixed with the n: qualifier. Note: Synopsys Design Constraints (SDC) is an accepted industry standard for communicating design intent to tools, particularly for timing analysis. A reference copy of the SDC specification is available from Synopsys by registering for the TAP-in program at: Precision mark_debug Syntax Examples The following are examples of VHDL and Verilog syntax when using Precision. VHDL Syntax Example attribute mark_debug : string; attribute mark_debug of char_fifo_dout: signal is "true"; Verilog Syntax Example (* mark_debug = "true" *) wire [7:0] char_fifo_dout; Synthesizing the Design The next step is to synthesize the design containing the debug core(s) by clicking Run Synthesis in the Vivado IDE or by running the following Tcl commands: launch_runs synth_1 wait_on_run synth_1 You can also use the synth_design Tcl command to synthesize the design. Refer to the Vivado Design Suite User Guide: Synthesis (UG901) [Ref 2] for more details on the various ways you can synthesize your design. Vivado Programming and Debugging 21

22 Using the Netlist Insertion Debug Probing Flow Marking Nets for Debug in the Synthesized Design Open the synthesized design by clicking Open Synthesized Design in the Flow Navigator and select the Debug window layout to see the Debug window. Any nets that correspond to HDL signals that were marked for debugging are shown in the Unassigned Debug Nets folder in the Debug window (see Figure 4-1). X-Ref Target - Figure 4-1 Figure 4-1: Unassigned Debug Nets You can mark additional nets in the synthesized design netlist for debugging using any of three methods: 1. Selecting a net in any of the design views (such as the Netlist or Schematic windows), then right-click select the Mark Debug option. 2. Selecting a net in any of the design views, then dragging and dropping the nets into the Unassigned Debug Nets folder. 3. Using the net selector in the Set up Debug wizard (see Using the Set Up Debug Wizard to Insert Debug Cores for details). Using the Set Up Debug Wizard to Insert Debug Cores The next step after marking nets for debugging is to assign them to debug cores. The Vivado IDE provides an easy to use Set up Debug wizard to help guide you through the process of automatically creating the debug cores and assigning the debug nets to the inputs of the cores. To use the Set up Debug wizard to insert the debug cores: 1. Optionally, select a set of nets for debugging either using the unassigned nets list or direct net selection. 2. Select Tools > Set up Debug from the Vivado IDE main menu. 3. Click Next to get to the Specify Nets to Debug panel (see Figure 4-2). Vivado Programming and Debugging 22

23 Using the Netlist Insertion Debug Probing Flow 4. Optionally, click Add/Remove Nets to add more nets or remove existing nets from the table. 5. Right-click on a debug net and select Select Clock Domain to change the clock domain that will be used to sample value on the net. Note: The Set up Debug wizard will attempt to automatically select the appropriate clock domain for the debug net by searching the path for synchronous elements. Use the Select ClockDomain dialog window to modify this selection as needed, but be aware that each clock domain present in the table will result in a separate ILA v2.0 core instance. 6. Once you are satisfied with the debug net selection, click Next. Note: The ChipScope wizard inserts one ILA core per clock domain. The nets that were selected for debug are assigned automatically to the probe ports of the inserted ILA v2.0 cores. he last wizard screen shows the core creation summary displaying the number of clocks found and ILA cores to be created and/or removed. 7. If you are satisfied with the results, click Finish to insert and connect the ILA v2.0 cores in your synthesized design netlist. X-Ref Target - Figure 4-2 Figure 4-2: Set Up Debug Wizard Vivado Programming and Debugging 23

24 Using the Netlist Insertion Debug Probing Flow Using the Debug Window to Add and Customize Debug Cores The Debug window provides more fine-grained control over ILA v2.0 core insertion than what is available in the Set up Debug wizard. The controls available in this window allow core creation, core deletion, debug net connection, and core parameter changes. The Debug window: Shows the list of debug cores that are connected to the debug_core_hub core. Maintains the list of unassigned debug nets at the bottom of the window. You can manipulate debug cores and ports from the popup menu or the toolbar buttons on the top of the window. Creating and Removing Debug Cores To create debug cores in the Debug window, click Create Debug Core. Using this interface (see Figure 4-3), you can change the parent instance, debug core name, and set parameters for the core. To remove an existing debug core, right-click on the core in the Debug window and select Delete. Click Finish to insert and connect the ILA v2.0 cores in your synthesized design netlist. X-Ref Target - Figure 4-3 Figure 4-3: Creating a New Debug Core Adding, Removing, and Customizing Debug Core Ports In addition to adding and removing debug cores, you can also add, remove, and customize ports of each debug core to suit your debugging needs. To add a new debug port: Vivado Programming and Debugging 24

25 Using the Netlist Insertion Debug Probing Flow 1. Select the debug core in the Debug window. 2. Click Create Debug Port to open the dialog shown in Figure Select or type in the port width 4. Click OK. 5. To remove a debug port, first select the port on the core in the Debug window, then select Delete. X-Ref Target - Figure 4-4 Figure 4-4: Creating a New Debug Port Connecting and Disconnecting Nets to Debug Cores You can select, drag, and drop nets and buses (also called bus nets) from the Schematic or Netlist windows onto the debug core ports. This expands the debug port as needed to accommodate the net selection. You can also right-click on any net or bus, and select Assign to Debug Port. IMPORTANT: You should avoid connecting multiple different nets or buses to the same probe port of the ILA v2.0 core due to a limitation in the way these aggregated probe ports are handled in the Vivado logic analyzer. Instead, you should allocate a single probe port for each unique net or bus. To disconnect nets from the debug core port, select the nets that are connected to the debug core port, and click Disconnect Net. Vivado Programming and Debugging 25

26 Using the Netlist Insertion Debug Probing Flow Modifying Properties on the Debug Cores Each debug core has properties you can change to customize the behavior of the core. To learn how to change properties on the debug_core_hub debug core, refer to Changing the BSCAN User Scan Chain of the Debug Core Hub, page 31. You can also change properties on the ILA v2.0 debug core. For instance, to change the number of samples captured by the ILA v2.0 debug core (see Figure 4-5), do the following: 1. In the Debug window, select the desired ILA core (such as u_ila_0). 2. In the Instance Properties window, select the Debug Core Options view. 3. Using the C_DATA_DEPTH pull-down list, select the desired number of samples to be captured. X-Ref Target - Figure 4-5 Figure 4-5: Changing the Data Depth of the ILA v2.0 Core Vivado Programming and Debugging 26

27 Using the Netlist Insertion Debug Probing Flow Using Tcl Commands Insert Debug Cores In addition to using the Set up Debug wizard, you can also use Tcl commands to create, connect, and insert debug cores into your synthesized design netlist: 1. Create the ILA v2.0 core black box. create_debug_core u_ila_0 labtools_ilalib_v2 2. Set the data depth property of the ILA v2.0 core. set_property C_DATA_DEPTH 1024 [get_debug_cores u_ila_0] 3. Set the width of the CLK port of the ILA v2.0 core to 1 and connect it to the desired clock net. set_property port_width 1 [get_debug_ports u_ila_0/clk] connect_debug_port u_ila_0/clk [get_nets [list clk ]] Note: You do not have to create the CLK port of the ILA v2.0 core because it is automatically created by the create_debug_core command. 4. Set the width of the PROBE0 port to the number of nets you plan to connect to the port. set_property port_width 1 [get_debug_ports u_ila_0/probe0] Note: You do not have to create the first probe port (PROBE0) of the ILA v2.0 core because it is automatically created by the create_debug_core command. 5. Connect the PROBE0 port to the nets you want to attach to that port. connect_debug_port u_ila_0/probe0 [get_nets [list A_or_B]] 6. Optionally, create more probe ports, set their width, and connect them to the nets you want to debug. create_debug_port u_ila_0 PROBE set_property port_width 2 [get_debug_ports u_ila_0/probe1] connect_debug_port u_ila_0/probe1 [get_nets [list {A[0]} {A[1]}]]to debug 7. Optionally, generate and synthesize the debug core(s) so you can floorplan them with the rest of your synthesized design. implement_debug_cores [get_debug_cores] For more information on these and other related Tcl commands, type help category ChipScope in the Tcl Console of the Vivado IDE. Implementing the Design After inserting, connecting and customizing your debug cores, you are now ready for implementing your design (refer to the section called Implementing the Design Containing the Debug Cores). Vivado Programming and Debugging 27

28 HDL Instantiation Debug Probing Flow Overview HDL Instantiation Debug Probing Flow Overview The HDL instantiation probing flow involves the manual customization, instantiation, and connection of various debug core components directly in the HDL design source. The debug cores that are supported in this flow in the Vivado tool are shown in table Table 4-2. Table 4-2: Debug Cores available for use in the HDL Instantiation Probing Flow Debug Core Version Description Run-time Analyzer Tool ICON (Integrated Controller) VIO (Virtual Input/Output) ILA (Integrated Logic Analyzer) ILA (Integrated Logic Analyzer) v1.06a v1.05a v1.05a Debug core hub used to connect the ILA 1.05a and VIO 1.05a cores to the JTAG chain. Debug core that is used to monitor or control signals in a design at JTAG chain scan rates. Requires connection to an ICON core. Debug core that is used to trigger on hardware events and capture data at system speeds. Requires connection to an ICON core. v2.0 Debug core that is used to trigger on hardware events and capture data at system speeds. The ICON, VIO, and ILA v1.x cores are supported in the Vivado tool flow in order to provide compatibility with legacy designs that contain these cores. The new ILA v2.0 core has two distinct advantages over the legacy ILA v1.x core: Works with the integrated Vivado logic analyzer feature (refer to Debugging the Design in Hardware, page 34). No ICON core instance or connection is required. ChipScope Pro Analyzer ChipScope Pro Analyzer ChipScope Pro Analyzer Vivado logic analyzer IMPORTANT: The ILA v2.0 HDL instantiation flow will result in a black box instance in your post-synthesis design netlist. This black box will be replaced with the fully populated ILA v2.0 core during the opt_design or place_design steps of the design implementation process. Using the HDL Instantiation Debug Probing Flow The steps required to perform the HDL instantiation flow are: Vivado Programming and Debugging 28

29 Using the HDL Instantiation Debug Probing Flow 1. Customize and generate the ILA v2.0 debug core(s) that have the right number of probe ports for the signals you want to probe. 2. Synthesize the design containing the debug core(s). 3. (Optional) Modify debug core properties. 4. Implement the design containing the debug core(s). Customizing and Generating the Debug Cores Use the IP Catalog button in the Project Manager to locate, select, and customize the desired debug core. The debug cores are located in the Debug & Verification > Debug category of the IP Catalog (see Figure 4-6). You can customize the debug core by double-clicking on the IP core or by right-click selecting the Customize IP menu selection. For more information on customizing the ILA v2.0 core, please refer to LogiCORE IP ChipScope Pro Integrated Logic Analyzer (ILA) (v2) Datasheet (DS875). After customizing the core, click the Generate button in the IP customization wizard. This will generate the customized debug core and add it to the Sources view of your project. X-Ref Target - Figure 4-6 Figure 4-6: Debug Cores in the IP Catalog Vivado Programming and Debugging 29

30 Using the HDL Instantiation Debug Probing Flow Instantiating the Debug Cores After generating the debug core, instantiate it in your HDL source code and connect it to the signals that you wish to probe for debugging purposes. Below is an example of the ILA v2.0 instance in a Verilog HDL source file: ila_v2_0_0 i_ila (.CLK(clk),.PROBE0(counterA),.PROBE1(counterB),.PROBE2(counterC),.PROBE3(counterD),.PROBE4(A_or_B),.PROBE5(B_or_C),.PROBE6(C_or_D),.PROBE7(D_or_A) ); Note: The legacy VIO and ILA v1.x cores require a connection to an ICON v1.x core. The ILA v2.0 core instance does not require a connection to an ICON core instance. Instead, a debug_core_hub debug core will automatically be inserted into the synthesized design netlist to provide connectivity between the ILA v2.0 core and the JTAG scan chain. Synthesizing the Design Containing the Debug Cores In the next step, synthesize the design containing the debug core(s) by clicking Run Synthesis in the Vivado IDE or by running the following Tcl commands: launch_runs synth_1 wait_on_run synth_1 You can also use the synth_design Tcl command to synthesize the design. Refer to Vivado Design Suite User Guide: Synthesis (UG901) [Ref 2] for more details on the various ways you can synthesize your design. IMPORTANT: The ILA v2.0 core that you add to your design is a black box instance that will be replaced with the fully populated ILA v2.0 core during the opt_design or place_design steps of the design implementation process. You can safely ignore the following critical warning that appears during the synthesis process: CRITICAL WARNING: [Designutils ] Could not resolve non-primitive black box cell 'ila' instantiated in module 'inst'. Viewing the Debug Cores in the Synthesized Design After synthesizing your design, you can open the synthesized design to view the debug cores and modify their properties. Open the synthesized design by clicking Open Synthesized Design in the Flow Navigator and select the Debug window layout to see the Debug window that shows your ILA v2.0 debug core(s) connected to the debug_core_hub (see Figure 4-7). Vivado Programming and Debugging 30

31 Using the HDL Instantiation Debug Probing Flow X-Ref Target - Figure 4-7 Figure 4-7: Debug Window Showing ILA v2.0 Core and Debug Core Hub Changing the BSCAN User Scan Chain of the Debug Core Hub You can view and change the BSCAN user scan chain index of the debug_core_hub by selecting the debug_core_hub in the Debug window, selecting the Debug Core Options view in the Properties window, then changing the value of the C_USER_SCAN_CHAIN property (see Figure 4-8). IMPORTANT: If you plan to mix legacy ICON, ILA, and/or VIO v1.x cores with ILA v2.0 cores, you will need to set the C_USER_SCAN_CHAIN property of the debug_core_hub to a user scan chain that does not conflict with the ICON v1.x core s Boundary Scan Chain setting. Failure to do so will result in errors later in the implementation flow. Vivado Programming and Debugging 31

32 Implementing the Design Containing the Debug Cores X-Ref Target - Figure 4-8 Figure 4-8: Changing the user scan chain property of the debug_core_hub Implementing the Design Containing the Debug Cores The Vivado software creates the debug_core_hub debug cores initially as black boxes. These cores must be implemented prior to running the placer and router. Implementing the Debug Cores Debug core implementation is done automatically when implementing the design; however, you can also force debug core implementation manually for floorplanning or timing analysis. To manually implement the cores: do one of the following: Click on the Implement Debug Cores icon on the toolbar menu of the Debug window. Right-click on any debug core in the Debug window and select the Implement Debug Cores option from the popup menu. Vivado Programming and Debugging 32

33 Implementing the Design Containing the Debug Cores The Vivado IDE will generate and synthesize each black box debug core. This operation can take some time. A progress indicator shows that the operation is running. When the debug core implementation is complete, the debug core black boxes are resolved and you can access the generated instances. Implementing the Design Implement the design containing the debug core(s) by clicking Run Implementation in the Vivado IDE or by running the following Tcl commands: launch_runs impl_1 wait_on_run impl_1 You can also implement the design using the implementation commands opt_design, place_design, and route_design. Refer to the Vivado Design Suite User Guide: Implementation (UG904) [Ref 3] for more details on the various ways you can implement your design. Vivado Programming and Debugging 33

34 Chapter 5 Debugging the Design in Hardware Introduction Once you have the debug core(s) in your design, you can use the run-time logic analyzer features to debug the design in hardware. Two different tools can be used depending on the type of debug cores in your design: ChipScope Pro Analyzer: used with ICON v1.x, ILA v1.x, VIO v1.x, and all IBERT debug cores. Vivado logic analyzer feature: used with ILA v2.0 debug cores. If you have a mixture of ICON/ILA/VIO v1.x and ILA v2.0 debug cores in your design, you can simultaneously use both the ChipScope Pro Analyzer tool and Vivado logic analyzer feature to debug the same design running on the same hardware target board (see section called Using Vivado Logic Analyzer to Debug the Design, page 35 for more details). Launching ChipScope Pro Analyzer to Debug the Design The ChipScope Pro Analyzer tool is used to interact with ICON v1.x, ILA v1.x, and VIO v1.x debug cores that are in your design. When the ChipScope Pro Analyzer software is installed, you can launch it directly from the Vivado IDE on any implemented design on which Generate Bitstream has been run. To launch ChipScope Pro Analyzer, do one of the following: Use the Flow > Launch ChipScope Analyzer command from the main menu Run the launch_chipscope_analyzer Tcl command in the Tcl Console The Vivado IDE passes the BIT bitstream and CDC net connection name files automatically to the ChipScope Pro Analyzer tool. For more information about ChipScope Pro Analyzer see the Xilinx website, Vivado Programming and Debugging 34

35 Using Vivado Logic Analyzer to Debug the Design Using Vivado Logic Analyzer to Debug the Design The Vivado logic analyzer feature is used to interact with ILA v2.0 debug cores that are in your design. To access the Vivado logic analyzer feature, click the Open Hardware Session button in the Program and Debug section of the Flow Navigator. The steps to debug your design in hardware are: 1. Connect to the hardware target and program the FPGA device with the.bit file 2. Set up the ILA debug core trigger and probe compare conditions. 3. Arm the ILA debug core trigger. 4. View the captured data from the ILA debug core in the Waveform window. Connecting to the Hardware Target and Programming the FPGA Device Programming an FPGA device prior to debugging are exactly the same steps described in Using a Vivado Hardware Session to Program an FPGA Device in Chapter 2. After programming the device with the.bit file that contains the ILA v2.0 core, the Hardware window now shows the ILA core that was detected when scanning the device (see Figure 5-1). X-Ref Target - Figure 5-1 Figure 5-1: Hardware Window Showing the ILA Debug Core Vivado Programming and Debugging 35

36 Setting up the ILA Core to Take a Measurement Setting up the ILA Core to Take a Measurement The ILA core(s) that you add to your design appear in the Hardware window under the target device. If you do not see the ILA core(s) appear, right-click on the device and select Refresh Hardware. This re-scans the FPGA device and refreshes the Hardware window. Note: If you still do not see the ILA core after programming and/or refreshing the FPGA device, check to make sure the device was programmed with the appropriate.bit file and check to make sure the implemented design contains an ILA v2.0 core. Click the ILA core (called hw_ila_1 in Figure 5-1) to see its properties in the ILA Core Properties window. You can also change several ILA core settings in the Hardware window: Trigger condition Trigger position Data depth Setting the ILA Core Trigger Condition Use the Trigger Cond control in the Hardware window (or the Trigger Condition property in the ILA Core Properties window) to select between AND and OR settings. The AND setting causes a trigger event when all of the ILA probe comparisons are satisfied. The OR setting causes a trigger event when any of the ILA probe comparisons are satisfied. You can also use the set_property Tcl command to change the ILA core trigger condition: set_property CONTROL.TRIGGER_CONDITION AND [get_hw_ilas hw_ila_1] Setting the ILA Core Trigger Position Use the Trigger Pos control in the Hardware window (or the Trigger Position property in the ILA Core Properties window) to set the position of the trigger mark in the captured data buffer. You can set the trigger position to any sample number in the captured data buffer. For instance, in the case of a captured data buffer that is 1024 samples deep: Sample number 0 corresponds to the first (left-most) sample in the captured data buffer. Sample number 1023 corresponds to the last (right-most) sample in the captured data buffer. Samples numbers 511 and 512 correspond to the two center samples in the captured data buffer. Vivado Programming and Debugging 36

37 Writing ILA Probes Information You can also use the set_property Tcl command to change the ILA core trigger position: set_property CONTROL.TRIGGER_POSITION 512 [get_hw_ilas hw_ila_1] Setting the ILA Core Data Depth Use the Data Depth control in the Hardware window (or the Capture data depth property in the ILA Core Properties window) to set the data depth of the ILA core captured data buffer. You can set the data depth to any power of two from 1 to the maximum data depth. Note: Refer to the section called Modifying Properties on the Debug Cores, page 26 for more details on how to set the maximum capture buffer data depth on ILA cores that are added to the design using the Netlist Insertion probing flow. You can also use the set_property Tcl command to change the ILA core trigger position: set_property CONTROL.DATA_DEPTH 512 [get_hw_ilas hw_ila_1] Writing ILA Probes Information The ILA Probes window contains information about the nets that you probed in your design using the ILA v2.0 core. This ILA probe information is extracted from your design and is stored in a data file that typically has an.ltx file extension. Normally, the ILA probe file is automatically created during the implementation process. However, you can also use the write_debug_probes Tcl command to write out the debug probes information to a file: 1. Open the Synthesized or Netlist Design. 2. Run the write_debug_probes filename.ltx Tcl command. Reading ILA Probes Information The ILA probe file is automatically associated with the FPGA hardware device if the probes file is called debug_nets.ltx and is found in the same directory as the bitstream programming (.bit) file that is associated with the device. You can also specify the location of the probes file: 1. Select the FPGA device in the Hardware window. 2. Set the Probes file location in the Hardware Device Properties window. 3. Click Apply to apply the change. Vivado Programming and Debugging 37

38 Viewing ILA Probes You can also set the location using the set_property Tcl command: set_property PROBES.FILE {C:/myprobes.ltx} [lindex [get_hw_devices] 0] Viewing ILA Probes The ILA Probes window is used to view the probes associated with each ILA core. Once the probes file is associated with the FPGA hardware device, select the hardware device and use the right-click Refresh Device command to refresh the ILA Probes window (see Figure 5-2). X-Ref Target - Figure 5-2 Figure 5-2: ILA Probes Window Setting Up the ILA Probe Trigger Compare Values The ILA probe trigger comparators are used to detect specific equality or inequality conditions on the probe inputs to the ILA v2.0 core. The trigger condition is the result of a Boolean AND or OR calculation of each of the ILA probe trigger comparator results (see section called Setting the ILA Core Trigger Condition, page 36 for more details). To specify the compare values for a given ILA probe, select the Compare Value cell in the ILA Probes window to open the Compare Value dialog box (see Figure 5-3 ). X-Ref Target - Figure 5-3 Figure 5-3: ILA Probe Compare Value Dialog Box Vivado Programming and Debugging 38

39 ILA Probe Compare Value Settings ILA Probe Compare Value Settings The Compare Value dialog box contains three fields that you can configure: 1. Operator: This is the comparison operator that you can set to the following values: == (equal)!= (not equal) < (less than) <= (less than or equal) > (greater than) >= (greater than or equal) 2. Radix: This is the radix or base of the Value that you can set to the following values: [B] Binary [H] Hexadecimal [O] Octal [A] ASCII [U] Unsigned Decimal [S] Signed Decimal 3. Value: This is the comparison value that will be compared (using the Operator) with the real-time value on the net(s) in the design that are connected to the probe input of the ILA v2.0 debug core. Depending on the Radix settings, the Value string is as follows: Binary - 0: logical zero - 1: logical one - X: don t care - R: rising or low-to-high transition - F: falling or high-to-low transition - B: either low-to-high or high-to-low transitions - N: no transition (current sample value is the same as the previous value) Hexadecimal - X: All bits corresponding to the value string character are don t care values - 0-9: Values 0 through 9 Vivado Programming and Debugging 39

40 Running or Arming the ILA Core Trigger - A-F: Values 10 through 15 Octal - X: All bits corresponding to the value string character are don t care values - 0-7: Values 0 through 7 ASCII - Any string made up of ASCII characters Unsigned Decimal - Any non-negative integer value Signed Decimal - Any integer value Running or Arming the ILA Core Trigger You can run or arm the ILA core trigger in two different modes: Run Trigger: Selecting the ILA core to be armed followed by clicking the Run Trigger button on the Hardware window toolbar arms the ILA core to detect the trigger event that is defined by the ILA core trigger condition and probe compare values. Run Trigger Immediate: Selecting the ILA core to be armed followed by clicking the Run Trigger Immediate button on the Hardware window toolbar arms the ILA core to trigger immediately regardless of the settings of the ILA core trigger condition and probe compare values. This command is useful for capturing any values that present at the probe inputs of the ILA core. Vivado Programming and Debugging 40

41 Stopping the ILA Core Trigger You can also arm the trigger by selecting and right-clicking on the ILA core and selecting Run Trigger or Run Trigger Immediate from the popup menu (see Figure 5-4). X-Ref Target - Figure 5-4 Figure 5-4: ILA Core Trigger Commands Stopping the ILA Core Trigger You can stop the ILA core trigger by selecting the appropriate ILA core followed by clicking on the Stop Trigger button on the Hardware window toolbar. You can also stop the trigger by selecting and right-clicking on the appropriate ILA core and selecting Stop Trigger from the popup menu (see Figure 5-4). Viewing the ILA Core State The State column in the Hardware window indicates the current state or status of each ILA core (see Table 5-1). Table 5-1: ILA Core State Description ILA Core State Description IDLE ARMED CAPTURING FULL The ILA core is idle and waiting for its trigger to be armed. The ILA core trigger is armed and is waiting for the trigger condition to be satisfied. This is the state when the trigger has been armed with the trigger position set to 0. The ILA core is capturing data into its data capture buffer. If the trigger position is set to a value greater than 0, this state also means that the trigger is armed. The ILA core capture buffer is full and is being uploaded to the host for display. Vivado Programming and Debugging 41

42 Viewing Captured Data from the ILA Core in the Waveform Viewer Viewing Captured Data from the ILA Core in the Waveform Viewer Once the ILA core captured data has been uploaded to the Vivado IDE, it is displayed in the Waveform Viewer. See Chapter 6, Viewing ILA Probe Data Using Waveform Viewer for details on using the Waveform Viewer to view captured data from the ILA core. Saving and Restoring Captured Data from the ILA Core In addition to displaying the captured data that is directly uploaded from the ILA core, you can also write the captured data to a file then read the data from a file and display it in the waveform viewer. Saving Captured ILA Data to a File Currently, the only way to upload captured data from an ILA core and save it to a file is to use the following Tcl command: write_hw_ila_data my_hw_ila_data_file [upload_hw_ila_data hw_ila_1] Restoring Captured ILA Data from a File Currently, the only way to restore captured data from a file and display it in the waveform viewer is to use the following Tcl command: display_hw_ila_data [read_hw_ila_data my_hw_ila_data_file] Using Vivado Logic Analyzer in a Lab Environment The Vivado logic analyzer feature is integrated into the Vivado IDE. In order to use Vivado logic analyzer feature to debug a design that is running on a target board that is in a lab environment, you need to do one of two things: Install and run the full Vivado IDE on your lab machine. Install the ISE Lab Tools 14.2 on your lab machine, and use the Vivado logic analyzer feature on your local machine to connect to a remote instance of the CSE Server. Vivado Programming and Debugging 42

43 Using Vivado Logic Analyzer in a Lab Environment Installing and Running the Full Vivado IDE on a Lab Machine The requirements for installing the Vivado IDE on your lab machine are found in Vivado Design Suite Installation and LIcensing Guide (UG798) [Ref 4]. The Vivado logic analyzer feature graphical user interface is only available in Project mode, but it does not require the original project used to create the design. The Vivado logic analyzer only needs two files from the original project: the bitstream programming (.bit) file and the probes (.ltx) file. Here are the steps to use the Vivado logic analyzer feature on a lab machine. 1. Install the Vivado IDE on your lab machine. 2. Copy the bitstream programming (.bit) file and the probes (.ltx) file to the lab machine. 3. Start Vivado IDE in GUI mode. 4. Create a sample project without any source, IP, or constraint files. 5. Click on the Open Hardware Session button in the Flow Navigator. 6. Follow the steps in the Connecting to the Hardware Target and Programming the FPGA Devices section to open a connection to the target board that is connected to your lab machine. Use the bitstream programming (.bit) file that you copied to the lab machine to program target FPGA device. 7. Follow the steps in the Setting up the ILA Core to Take a Measurement section and beyond to debug your design in hardware. Use the probes (.ltx) file that you copied to the lab machine when you get to the Reading ILA Probes Information section. Connecting to a Remote CSE Server Running on a Lab Machine If you have a network connection to your lab machine, you can also connect to the target board by connecting to a CSE server that is running on that remote lab machine. Here are the steps to using the Vivado logic analyzer feature to connect to a CSE server that is running on the lab machine: 1. Install the ISE Lab Tools 14.2 on the lab machine. 2. Start up the cse_server application on the remote lab machine. Assuming you installed the ISE Lab Tools 14.2 to the default location and your lab machine is a 64-bit Windows machine, here is the command line: C:\Xilinx\14.2\LabTools\LabTools\bin\nt64\cse_server port Start Vivado IDE in GUI mode on a different machine than your lab machine. 4. Follow the steps in the Connecting to the Hardware Target and Programming the FPGA Device section to open a connection to the target board that is connected to your lab machine. However, instead of connecting to a CSE server running on localhost, use the host name of your lab machine. Vivado Programming and Debugging 43

44 Using Vivado Logic Analyzer and ChipScope Pro Analyzer Simultaneously 5. Follow the steps in the Setting up the ILA Core to Take a Measurement section and beyond to debug your design in hardware. Using Vivado Logic Analyzer and ChipScope Pro Analyzer Simultaneously You can use the Vivado logic analyzer feature and ChipScope Pro Analyzer tools to simultaneously debug the same design running on the same target board. Some examples of situations where this capability becomes important are: You have a design that contains an ILA v2.0 debug core and a VIO v1.x debug core that you need to interact with using the Vivado logic analyzer feature and ChipScope Pro Analyzer feature, respectively. You want to interact with an ILA v2.0 debug core in your design using the Vivado logic analyzer feature and you want to monitor the XADC temperature or voltage sensors using the ChipScope Pro Analyzer tool s System Monitor feature. You have a 7 series device and a 6 series device that you need to debug at the same time using the Vivado logic analyzer feature and the ChipScope Pro Analyzer feature, respectively. This section covers the first case of having both an ILA v2.0 debug core and a VIO v1.x debug core in the same design. The steps that you need to follow to take advantage of this capability are: 1. Use two separate BSCAN user scan chains, one for each JTAG controller core. 2. Start two separate CSE servers, one for each run-time analyzer applications. 3. Use two different run-time analyzer applications, the Vivado logic analyzer feature and ChipScope Pro Analyzer tool. Using Separate BSCAN User Scan Chains Make sure that the debug_core_hub core (which is used to connect the ILA v2.0 core to a BSCANE2 primitive) and the ICON v1.x core (which is used to connect the VIO v1.x core to a BSCANE2 primitive) are configured to use different user scan chains (see section Changing the BSCAN User Scan Chain of the Debug Core Hub in Chapter 4 for more details). Setting Up Separate CSE Servers Make sure two separate CSE server instances are running on the machine that is connected to the target board. For instance, on a Windows platform, do the following in two separate cmd windows: Vivado Programming and Debugging 44

45 Using Vivado Logic Analyzer and ChipScope Pro Analyzer Simultaneously In the first cmd window, run cse_server port In the second cmd window, run cse_server port The CSE server running on ports and will be used by the Vivado logic analyzer feature and ChipScope Pro Analyzer tool, respectively. Running Vivado Logic Analyzer Feature and ChipScope Pro Analyzer Tool Now that you have set up the design and the CSE servers, you can use the Vivado logic analyzer feature and ChipScope Pro Analyze tool to debug the design by following these steps: 1. Start the Vivado IDE in GUI mode. 2. Click Open Hardware Session in the Flow Navigator. 3. Connect to the CSE server that is running on localhost:50001, and program the target device (see Using a Vivado Hardware Session to Program an FPGA Device in Chapter 2 for more details) 4. Launch the ChipScope Pro Analyzer using the Flow>Launch ChipScope Analyzer menu command. 5. In the ChipScope Pro Analyzer tool, select JTAG Chain>Server Host Setting. Change the server to localhost:50002 (see Figure 5-5) X-Ref Target - Figure 5-5 Figure 5-5: Changing the ChipScope Pro Analyzer Server Host Settings 6. In the ChipScope Pro Analyzer, connect to the target board using the appropriate cable in the JTAG Chain menu. Vivado Programming and Debugging 45

46 Description of Hardware Session Tcl Objects and Commands 7. Use each of the run-time analyzer tools to interact with their respective debug cores (see Figure 5-6 ) X-Ref Target - Figure 5-6 Figure 5-6: Using Vivado Logic Analyzer Feature and ChipScope Pro Analyzer Tool to Debug the Design Description of Hardware Session Tcl Objects and Commands You can use Tcl commands to interact with your hardware under test. The hardware is organized in a set of hierarchical first class Tcl objects (see Table 5-2). Table 5-2: Tcl Object hw_server hw_target hw_device hw_ila Hardware Session Tcl Objects Description Object referring to CSE server. Each hw_server can have one or more hw_target objects associated with it. Object referring to JTAG cable or board. Each hw_target can have one or more hw_device objects associated with it. Object referring to a device in the JTAG chain, including Xilinx FPGA devices. Each hw_device can have one or more hw_ila objects associated with it. Object referring to an ILA core in the Xilinx FPGA device. Each hw_ila object can have only one hw_ila_data object associated with it. Each hw_ila object can have one or more hw_probe objects associated with it. Vivado Programming and Debugging 46

47 Description of Hardware Session Tcl Objects and Commands Table 5-2: Tcl Object hw_ila_data hw_probe Object referring to data uploaded from an ILA debug core. Object referring to the probe input of an ILA debug core. For more information about the hardware session commands, run the help category hardware Tcl command in the Tcl Console. Description of hw_server Tcl Commands Table 5-3 contains descriptions of all Tcl commands used to interact with hardware servers. Table 5-3: Descriptions of hw_server Tcl Commands Tcl Command Description connect_hw_server current_hw_server disconnect_hw_server get_hw_servers refresh_hw_server Open a connection to a hardware server. Get or set the current hardware server. Close a connection to a hardware server. Get list of hardware server names for the CSE servers. Refresh a connection to a hardware server. Description of hw_target Tcl Commands Table 5-4 contains descriptions of all Tcl commands used to interact with hardware targets. Table 5-4: Descriptions of hw_target Tcl Commands Tcl Command Description close_hw_target current_hw_target get_hw_targets open_hw_target refresh_hw_target Hardware Session Tcl Objects (Cont d) Description Close a hardware target. Get or set the current hardware target. Get list of hardware targets for the hardware servers. Open a connection to a hardware target on the hardware server. Refresh a connection to a hardware target. Description of hw_device Tcl Commands Table 5-5 Descriptions of hw_device Tcl Commands contains descriptions of all Tcl commands used to interact with hardware devices. Vivado Programming and Debugging 47

48 Description of Hardware Session Tcl Objects and Commands Table 5-5: Descriptions of hw_device Tcl Commands Tcl Command Description current_hw_device get_hw_device program_hw_device refresh_hw_device Get or set the current hardware device. Get list of hardware devices for the target. Program Xilinx FPGA devices. Refresh a hardware device. Description of hw_ila Tcl Commands Table 5-6 Descriptions of hw_ila Tcl Commands contains descriptions of all Tcl commands used to interact with ILA v2.0 debug cores. Table 5-6: Descriptions of hw_ila Tcl Commands Tcl Command Description current_hw_ila get_hw_ilas reset_hw_ila run_hw_ila wait_on_hw_ila Get or set the current hardware ILA. Get list of hardware ILAs for the target. Reset hw_ila control properties to default values. Arm hw_ila triggers. Wait until all data has been captured. Description of hw_ila_data Tcl Commands Table 5-7 Descriptions of hw_ila_data Tcl Commands contains descriptions of all Tcl commands used to interact with captured ILA data. Table 5-7: Descriptions of hw_ila_data Tcl Commands Tcl Command Description current_hw_ila_data display_hw_ila_data get_hw_ila_data read_hw_ila_data upload_hw_ila_data write_hw_ila_data Get or set the current hardware ILA data Display hw_ila_data in waveform viewer Get list of hw_ila_data objects Read hw_ila_data from a file Stop the ILA core from capturing data and upload any captured data. Write hw_ila_data to a file. Description of hw_probe Tcl Commands Table 5-8 contains descriptions of all Tcl commands used to interact with captured ILA data. Vivado Programming and Debugging 48

49 Using Hardware Session Tcl Commands Table 5-8: Descriptions of hw_probe Tcl Commands Tcl Command Description get_hw_probes Get list of hardware probes. Using Hardware Session Tcl Commands Below is an example Tcl command script that interacts with the following example system: One KC705 board s Digilent JTAG-SMT1 cable (serial number 12345) accessible via a CSE server running on localhost: Single ILA core in a design running in the XC7K325T device on the KC705 board. ILA core has a probe called counter[3:0]. Example Tcl Command Script # Connect to the Digilent Cable on localhost:50001 connect_hw_server -host localhost -port current_hw_target [get_hw_targets */digilent_plugin/sn:12345] open_hw_target # Program and Refresh the XC7K325T Device current_hw_device [lindex [get_hw_devices] 0] refresh_hw_device -update_hw_probes false [lindex [get_hw_devices] 0] set_property PROGRAM.FILE {C:/design.bit} [lindex [get_hw_devices] 0] set_property PROBES.FILE {C:/design.ltx} [lindex [get_hw_devices] 0] program_hw_devices [lindex [get_hw_devices] 0] refresh_hw_device [lindex [get_hw_devices] 0] # Set Up ILA Core Trigger Position and Probe Compare Values set_property CONTROL.TRIGGER_POSITION 512 [get_hw_ilas hw_ila_1] set_property COMPARE_VALUE.0 eq4'b0000 [get_hw_probes counter] # Arm the ILA trigger and wait for it to finish capturing data run_hw_ila hw_ila_1 wait_on_hw_ila hw_ila_1 # Upload the captured ILA data, display it, and write it to a file current_hw_ila_data [upload_hw_ila_data hw_ila_1] display_hw_ila_data [current_hw_ila_data] write_hw_ila_data my_hw_ila_data [current_hw_ila_data] Vivado Programming and Debugging 49

50 Chapter 6 Viewing ILA Probe Data Using Waveform Viewer Introduction With the Vivado Integrated Design Environment (IDE) simulator open, you can begin working with the waveform to analyze your design and debug your code. The Vivado logic analyzer populates design data in other areas, such as the hardware and the ILA probes windows. Waveform Viewer Features and Limitations Waveform Feature Summary Analog waveform support for ILA probe vectors with a minimum width of 2. Real radix can apply to digital or analog waveforms. Waveform Limitations A maximum bus width of 64 bits on real numbers. Incorrect values are possible for buses wider than 64 bits. Floating point supports only 32- and 64-bit arrays. Switching between analog and digital waveform styles resets the row height to defaults (100 pixels for analog, 20 for digital). Wide arrays close to 64 bits with a radix other than real could contain rounding problems in Least Significant Bits (LSB). Vivado User Guide: Logic Simulation 50

51 Waveform Viewer Configuration Signals and Buses Waveform Viewer Configuration Signals and Buses The scalar and vector ILA probes in the Waveform window are the design objects in the waveform. The ILA probes display with a corresponding identifying button. You can hover the mouse over the button for a description. Figure 6-1 is an example of ILA probes in the Waveform Configuration window. X-Ref Target - Figure 6-1 Figure 6-1: Waveform ILA Probes The ILA probes display with an ID Number, Name, and Value. The toolbar buttons on the left give you access to navigation features that are described in the following sections. Vivado User Guide: Logic Simulation 51

52 ILA Probes in Waveform Configuration Using the Zoom Features You have zoom functions as sidebar buttons to zoom in and out of a wave configuration as needed. You can also use the mouse wheel with the CTRL key in combination after clicking within the waveform to zoom in and out to emulate the operation of the dials on an oscilloscope. Waveform Options Dialog Box When you select the Waveforms Options button shown in Figure 6-2, opens. the Waveform Options dialog box, X-Ref Target - Figure 6-2 The options are as follows: Figure 6-2: Waveform Options Dialog Box General: Set the default radix. Show signal indices: Checkbox inserts a small definition line between signal numbers. Colors: Lets you set colors for the objects within the waveform. ILA Probes in Waveform Configuration You can add ILA probe scalars and vectors, also called signals and buses, to the waveform configuration file, then save that configuration to a WDB file. You can populate the Wave window with the probes from your ILA core using menu commands, or using Tcl commands in the Tcl Console. To add ILA probes to the waveform configuration: Vivado User Guide: Logic Simulation 52

53 Customizing the Wave Configuration 1. In the ILA Probes window, expand the desired ILA core, and select a probe. 2. Right-click, and select Add to Wave window from the popup menu. You can add copies of the same signal or bus in a wave configuration for comparing waveforms. You can place copies of the same signal or bus anywhere in the wave configuration, such as in groups or virtual buses. To add a copy of a signal or bus, do the following: 1. Select a signal or bus in the wave configuration in the Wave window. 2. Select Edit > Copy or type Ctrl+C. The signal name is copied to the clipboard. 3. Select Paste or type Ctrl+V. The signal or bus is now copied to the wave configuration. You can move the signal or bus using drag and drop as needed. Customizing the Wave Configuration You can customize the Wave configuration using the features that are listed and briefly described in Table 6-1; the feature name links to the subsection that fully describes the feature. Table 6-1: Customization Features in the Wave Configuration Feature Description Cursors Markers Dividers Using Groups Using Virtual Buses Renaming Objects Displaying Names The main cursor and secondary cursor in the Wave window let you display and measure time, and they form the focal point for various navigation activities. You can add markers to navigate through the waveform, and to display the waveform value at a particular time. You can add a divider to create a visual separator of signals. You can add a group, that is a collection to which signals and buses can be added in the wave configuration as a means of organizing a set of related signals. You can add a virtual bus to your wave configuration, to which you can add logic scalars and arrays. You can rename objects, signals, buses, and groups. You can display the full hierarchical name (long name), the simple signal or bus name (short name), or a custom name for each signal. Vivado User Guide: Logic Simulation 53

54 Customizing the Wave Configuration Table 6-1: Customization Features in the Wave Configuration (Cont d) Feature Description Radixes Bus Bit Order Cursors The default radix controls the bus radix that displays in the wave configuration, Objects panel, and the Console panel. You can change the Bus bit order from Most Significant Bit (MSB) to Least Significant Bit (LSB) and vice versa. Cursors are used primarily for temporary indicators of sample position and are expected to be moved frequently, as in the case when you are measuring the distance (in samples) between two waveform edges. TIP: For more permanent indicators, used in situations such as establishing a time-base for multiple measurements, add markers to the Wave window instead. See Markers, page 54 for more information. You can place the main cursor with a single click in the Wave window. To place a secondary cursor, Ctrl+Click and hold the waveform, and drag either left or right. You can see a flag that labels the location at the top of the cursor. Alternatively, you can hold the SHIFT key and click a point in the waveform. The main cursor remains the original position, and the other cursor is at the point in the waveform that you clicked. Note: To preserve the location of the secondary cursor while positioning the main cursor, hold the Shift key while clicking. When placing the secondary cursor by dragging, you must drag a minimum distance before the secondary cursor appears. To move a cursor, hover over the cursor until you see the grab symbol, and click and drag the cursor to the new location. As you drag the cursor in the Wave window, you see a hollow or filled-in circle if the Snap to Transition button is selected, which is the default behavior. A hollow circle indicates that you are between transitions in the waveform of the selected signal. A filled-in circle indicates that you are hovering over the waveform transition of the selected signal. A secondary cursor can be hidden by clicking anywhere in the Wave window where there is no cursor, marker, or floating ruler. Markers Use a marker when you want to mark a significant event within your waveform in a permanent fashion. Markers allow you to measure distance (in samples) relevant to that marked event. Vivado User Guide: Logic Simulation 54

55 Customizing the Wave Configuration You can add, move, and delete markers as follows: You add markers to the wave configuration at the location of the main cursor. a. Place the main cursor at the sample number where you want to add the marker by clicking in the Wave window at the sample number or on the transition. b. Select Edit > Markers > Add Marker, or click the Add Marker button. A marker is placed at the cursor, or slightly offset if a marker already exists at the location of the cursor. The sample number of the marker displays at the top of the line. You can move the marker to another location in the waveform using the drag and drop method. Click the marker label (at the top of the marker) and drag it to the location. The drag symbol indicates that the marker can be moved. As you drag the marker in the Wave window, you see a hollow or filled-in circle if the Snap to Transition button is selected, which is the default behavior. A filled-in circle indicates that you are hovering over a transition of the waveform for the selected signal or over another marker. For markers, the filled-in circle is white. A hollow circle indicates that are you between transitions in the waveform of the selected signal. Release the mouse key to drop the marker to the new location. You can delete one or all markers with one command. Right-click over a marker, and do one of the following: Select Delete Marker from the popup menu to delete a single marker. Select Delete All Markers from the popup menu to delete all markers. Note: You can also use the Delete key to delete a selected marker. Use Edit > Undo to reverse a marker deletion. Trigger Marker The red trigger marker (whose label is a red letter 'T') is a special marker that indicates the occurrence of the trigger event in the capture buffer. The position of the trigger marker in the buffer directly corresponds to the Trigger Position setting (see section Setting the ILA Core Trigger Position in Chapter 5). Note: The trigger marker is not movable using the same technique as regular markers. Its position is set using the ILA core's Trigger Position property setting. Vivado User Guide: Logic Simulation 55

56 Customizing the Wave Configuration Dividers Dividers create a visual separator between signals. You can add a divider to your wave configuration to create a visual separator of signals, as follows: 1. In a Name column of the Wave window, click a signal to add a divider below that signal. 2. From the popup menu, select Edit > New Divider, or right-click and select New Divider. The change is visual and nothing is added to the HDL code. The new divider is saved with the wave configuration file when you save the file. You can move or delete Dividers as follows: Move a Divider to another location in the waveform by dragging and dropping the divider name. To delete a Divider, highlight the divider, and click the Delete key, or right-click and select Delete from the popup menu. Dividers can be renamed also; see Renaming Objects, page 57. Using Groups A Group is a collection of expandable and collapsible categories, to which you can add signals and buses in the wave configuration to organize related sets of signals. The group itself displays no waveform data but can be expanded to show its contents or collapsed to hide them. You can add, change, and remove groups. To add a Group: 1. In a wave configuration, select one or more signals or buses to add to a group. Note: A group can include dividers, virtual buses, and other groups. 2. Select Edit > New Group, or right-click and select New Group from the popup menu. A Group that contains the selected signal or bus is added to the wave configuration. A Group is represented with the Group button. The change is visual and nothing is added to the ILA core. You can move other signals or buses to the group by dragging and dropping the signal or bus name. You can move or remove Groups as follows: Move Groups to another location in the Name column by dragging and dropping the group name. Vivado User Guide: Logic Simulation 56

57 Renaming Objects Remove a group, by highlighting it and selecting Edit > Wave Objects > Ungroup, or right-click and select Ungroup from the popup menu. Signals or buses formerly in the group are placed at the top-level hierarchy in the wave configuration. Groups can be renamed also; see Renaming Objects, page 57. CAUTION! The Delete key removes the group and its nested signals and buses from the wave configuration. Using Virtual Buses You can add a virtual bus to your wave configuration, which is a grouping to which you can add logic scalars and arrays. The virtual bus displays a bus waveform, which shows the signal waveforms in the vertical order that they appear under the virtual bus, flattened to a one-dimensional array. You can then change or remove virtual buses after adding them. To add a virtual bus: 1. In a wave configuration, select one or more signals or buses you want to add to a virtual bus. 2. Select Edit > New Virtual Bus, or right-click and select New Virtual Bus from the popup menu. The virtual bus is represented with the Virtual Bus button. The change is visual and nothing is added to the HDL code. You can move other signals or buses to the virtual bus by dragging and dropping the signal or bus name. The new virtual bus and its nested signals or buses are saved when you save the wave configuration file. You can also move it to another location in the waveform by dragging and dropping the virtual bus name. You can rename a virtual bus; see Renaming Objects. To remove a virtual bus, and ungroup its contents, highlight the virtual bus, and select Edit > Wave Objects > Ungroup, or right-click and select Ungroup from the popup menu. CAUTION! The Delete key removes the virtual bus and its nested signals and buses from the wave configuration. Renaming Objects You can rename any object in the Wave window, such as signals, dividers, groups, and virtual buses. Vivado User Guide: Logic Simulation 57

58 Renaming Objects 1. Select the object name in the Name column. 2. Select Rename from the popup menu. 3. Replace the name with a new one. 4. Press Enter or click outside the name to make the name change take effect. You can also double-click the object name and then type a new name. The change is effective immediately. Object name changes in the wave configuration do not affect the names of the nets attached to the ILA core probe inputs. Displaying Names You can display the full hierarchical name (long name), the simple signal or bus name (short name), or a custom name for each signal. The signal or bus name displays in the Name column of the wave configuration. If the name is hidden: Expand the Name column until you see the entire signal name. Use the scroll bar in the Name column to view the name. To change the display name: 1. Select one or more signal or bus names. Use Shift+ click or Ctrl+ click to select many signal names. 2. Right-click, and select Name >: Long to display the full hierarchical name. Short to display the name of the signal or bus only. Custom to display the custom name given to the signal when renamed. The name changes immediately according to your selection. Radixes Understanding the type of data on your bus is important. You need to recognize the relationship between the radix setting and the data type to use the waveform options of Digital and Analog effectively. See About Radixes and Analog Waveforms, page 60 for more information about the radix setting and its effect on Analog waveform analysis. You can change the radix of an individual signal (ILA probe) in the Wave window as follows: 1. Right-click a bus in the Wave window. 2. Select Radix and the format you want from the drop-down menu: Binary Hexadecimal Vivado User Guide: Logic Simulation 58

59 Renaming Objects Unsigned Decimal Signed Decimal Octal ASCII IMPORTANT: Changes to the radix of an item in the Objects window do not apply to values in the Wave window or the Tcl Console. To change the radix of an individual signal (ILA probe) in the Wave window, use the Wave window popup menu. Maximum bus width of 64 bits on real. Incorrect values are possible for buses wider than 64 bits. Floating point supports only 32- and 64-bit arrays. Using the Floating Ruler The floating ruler assists with time measurements using a sample number base other than the absolute sample numbers shown on the standard ruler at the top of the Wave window. You can display (or hide) a floating ruler and move it to a location in the Wave window. The sample base (sample 0) of the floating ruler is the secondary cursor, or, if there is no secondary cursor, the selected marker. The floating ruler button and the floating ruler itself are visible only when the secondary cursor (or selected marker) is present. 1. Do either of the following to display or hide a floating ruler: Place the secondary cursor. Select a marker. 2. Select View > Floating Ruler, or click the Floating Ruler button. You only need to follow this procedure the first time. The floating ruler displays each time the secondary cursor is placed or a marker is selected. Select the command again to hide the floating ruler. Bus Bit Order You can reverse the bus bit order in the wave configuration to switch between MSB-first and LSB-first signal representation. To reverse the bit order: 1. Select a bus. 2. Right-click and select Reverse Bit Order. Vivado User Guide: Logic Simulation 59

60 About Radixes and Analog Waveforms The bus bit order is reversed. The Reverse Bit Order command is marked to show that this is the current behavior. About Radixes and Analog Waveforms Bus values are interpreted as numeric values, which are determined by the radix setting on the bus wave object, as follows: Binary, octal, hexadecimal, ASCII, and unsigned decimal radixes cause the bus values to be interpreted as unsigned integers. The format of data on the bus must match the radix setting. Any non-0 or -1 bits cause the entire value to be interpreted as 0. The signed decimal radix causes the bus values to be interpreted as signed integers. Real radixes cause bus values to be interpreted as fixed point or floating point real numbers, as determined by the settings of the Real Settings dialog box, shown in Figure 6-3, page 60. X-Ref Target - Figure 6-3 The options are as follows: Figure 6-3: Real Settings Dialog Box Fixed Point: Specifies that the bits of the selected bus wave object(s) is interpreted as a fixed point, signed, or unsigned real number. Vivado User Guide: Logic Simulation 60

61 About Radixes and Analog Waveforms Binary Point: Specifies how many bits to interpret as being to the right of the binary point. If Binary Point is larger than the bit width of the wave object, wave object values cannot be interpreted as fixed point, and when the wave object is shown in Digital waveform style, all values show as <Bad Radix>. When shown as analog, all values are interpreted as 0. Floating Point: Specifies that the bits of the selected bus wave object(s) should be interpreted as an IEEE floating point real number. Note: Only single precision and double precision (and custom precision with values set to those of single and double precision) are supported. Other values result in <Bad Radix> values as in Fixed Point. Exponent Width and Fraction Width must add up to the bit width of the wave object, or else <Bad Radix> values result. Viewing Analog Waveforms To convert a digital waveform to analog, do the following: 1. In the Name area of a Wave window, right-click on the bus for the popup menu. 2. Select Waveform Style and then Analog Settings to choose an appropriate drawing setting. The digital drawing of the bus converts to an analog format. You can adjust the height of either an analog waveform or a digital waveform by selecting and then dragging the rows. Figure 6-4 shows the Analog Settings dialog box with the settings for analog waveform drawing. Vivado User Guide: Logic Simulation 61

62 About Radixes and Analog Waveforms X-Ref Target - Figure 6-4 Figure 6-4: The Analog Settings dialog box options are as follows: Row Height: Specifies how tall to make the select wave object(s), in pixels. Changing the row height does not change how much of a waveform is exposed or hidden vertically, but rather stretches or contracts the height of the waveform. When switching between Analog and Digital waveform styles, the row height is set to an appropriate default for the style (20 for digital, 100 for analog). Y Range: Specifies the range of numeric values to be shown in the waveform area. Auto: Specifies that the range should continually expand whenever values in the visible time range of the window are discovered to lie outside the current range. Fixed: Specifies that the time range is to remain at a constant interval. Min: Specifies the value displays at the bottom of the waveform area. Max: Specifies the value displays at the top. Analog Settings Dialog Box Both values can be specified as floating point; however, if radix of the wave object radix is integral, the values are truncated to integers. Interpolation Style: Specifies how the line connecting data points is to be drawn. Linear: Specifies a straight line between two data points. Vivado User Guide: Logic Simulation 62