GOOD ChipScope e

1

THE CHIPSCOPE LOGIC ANALYZER

This laboratory work presents an introduction to the ChipScope logic analyzer of the Xilinx ISE design environment and describes the steps required to use this logic analyzer in a simple VHDL design.

1. Overview ChipScope is a software based logic analyzer that allows monitoring the status of se-lected signals in a design in order to detect possible design errors. It provides several cores that can be added to a design by generating the cores with the CORE Generator tool, instan-tiating them into the source code, and connecting the cores to the design before the synthesis process (Figure 1). Alternatively, it is possible to customize the cores and insert them into the design netlist using the ChipScope Core Inserter tool after the synthesis process. The design is then implemented into the FPGA device using the implementation tools of the Xilinx ISE design environment. Next, the user configures the FPGA device and analyzes the design with the graphical interface provided by the ChipScope Analyzer software. Monitoring the status of signals is possible by capturing and storing their values when certain events occur. The amount of data that can be stored is limited by the available Block RAM (BRAM) within the FPGA device. Users can set complex trigger conditions to specify when the data capture should start, which allows detecting the occurrence of certain events that are important for design verification and debug. The trigger conditions can be changed during the operation of the hardware without the need to recompile the design. Compared to hardware based logic analyzers, the ChipScope analyzer has several ad-vantages. One advantage is that hardware based logic analyzers are much more expensive. Another advantage is that by using the ChipScope analyzer it is possible to analyze a large number of signals (up to 1024), while traditional logic analyzers have a limited number (e.g., 16) of data channels, often insufficient to debug complex designs. Finally, the ChipScope ana-lyzer allows specifying much more complex triggering conditions and modes.

2. ChipScope Cores The main types of cores required for using the ChipScope analyzer are the following: ICON (Integrated CONtroller), ILA (Integrated Logic Analyzer), and VIO (Virtual In-put/Output). Additional cores are available for more complex designs or for attaching external logic analyzers to the FPGA device; these cores are not described in this document.

2.1. ICON Core

All of the ChipScope cores use the JTAG Boundary Scan port to communicate with the host computer via a JTAG downloading cable (either a parallel or a USB cable). The Inte-grated CONtroller (ICON) core provides a communications path between the JTAG Boun-dary Scan port of the FPGA device and the other ChipScope cores (ILA, VIO). The ICON core can communicate with up to 15 ILA and/or VIO cores at any given time. However, individual cores cannot share their control ports with any other core. There-fore, the ICON core needs a distinct control port for every ILA and VIO core.

2 Structure of Computer Systems

Figure 1. Design steps for using the ChipScope software.

The Boundary Scan primitive component is used to communicate with the JTAG Boundary Scan logic of the FPGA device. This component extends the JTAG Test Access Port (TAP) interface of the FPGA device so that up to four internal scan chains can be created, depending on the device family. The ChipScope Analyzer tool communicates with the ChipScope cores by using one of the internal scan chains provided by the Boundary Scan component. For instance, the Boundary Scan component of Spartan-3 and Spartan-3E devices provides two internal scan chains, USER1 and USER2. Since the ChipScope cores use a single internal scan chain of the Boundary Scan component, it is possible to share the Boundary Scan component with other elements of the users design. One of the following two methods can be used for this sharing:

Instantiating the Boundary Scan component inside the ICON core and including the unused Boundary Scan chain signals as ports on the ICON core interface. The Boun-dary Scan component is instantiated inside the ICON core by default.

Instantiating the Boundary Scan component somewhere else in the design and attach-ing the USER1 or USER2 scan chain signals to the corresponding ports of the ICON core interface.

When generating the ICON core, it is possible to enable the Include Boundary Scan Ports option to provide access to the unused scan chain interfaces. However, the Boundary Scan ports should be included only if the design needs them. If the ports are included and not used, the synthesis tools may not connect the ICON core properly, causing errors during the synthesis and implementation stages of the design. Figure 2 illustrates the communication between the ICON, ILA, and VIO cores.

3 The ChipScope Logic Analyzer

Figure 2. Communication between the ICON, ILA, and VIO cores.

2.2. ILA Core

The Integrated Logic Analyzer (ILA) core is a customizable logic analyzer core that can be used to monitor any internal signal of the design. Since the ILA core is synchronous to the design being monitored, all the clock signal constraints that are applied to that design are also applied to the components inside the ILA core. The ILA core consists of the following main components: trigger input and output logic, data capture logic, control and status logic. These components are described next.

2.2.1. Trigger Input Logic

The trigger input logic allows detecting complex trigger events. Each ILA core can have up to 16 trigger ports, and each port can be 1 to 256 bits wide. The ability to provide multiple trigger ports is necessary in complex systems where different types of signals or bus-es need to be monitored. To detect events on a trigger port, up to 16 comparators can be connected to that port. An individual comparator is called match unit. This feature enables multiple comparisons to be performed on the trigger port signals. The results of one or more match units are combined together to form the overall trigger condition event that is used to control data capture. Select-ing a single match unit conserves resources while still allowing some flexibility in detecting trigger events. Selecting two or more match units allows a more flexible trigger condition eq-uation. However, increasing the number of match units connected to a trigger port increases the usage of logic resources accordingly. The match units connected to the trigger ports can be one of the following types:

Basic comparator: Performs = and () comparisons.

Basic comparator w/edges: Similar to the basic comparator, but also detects high-to-low and low-to-high transitions.

Extended comparator: Performs =, (), >, >=, =,


At least n occurrences: The match signal is asserted and remains asserted once n consecutive or non-consecutive events occur.

At least n consecutive occurrences: The match signal is asserted when n consecutive events occur, and remains asserted until the match function is not satisfied.

The internal trigger condition of the ILA core can be accessed using the optional trig-ger output port. The signal on this port can be used as a trigger signal for external test equip-ment by attaching the signal to an output pin. This signal can also be used by internal logic as an interrupt, a trigger, or to cascade multiple ILA cores together. The shape (level or pulse) and sense (active-High or active-Low) of the trigger output can be controlled at runtime. In order to monitor different kinds of signals and buses in a design, multiple trigger ports can be used. For example, if the design includes an internal system bus that consists of control, address, and data signals, then a separate trigger port can be assigned to monitor each signal group, as shown in Figure 3. If all of these different signals and buses would be con-nected to a single trigger port, it would not be possible to monitor for individual bit transitions on the CE, WE, and OE signals while looking for the Address bus to be in a specified range.

Figure 3. ILA core connection example.

A trigger condition is a Boolean or sequential combination of events that is detected by match unit comparators attached to the trigger ports of the ILA core. The trigger condition is used to specify the initial point in the data capture window and can be located at the begin-ning, the end, or anywhere within the data capture window. A storage qualification condition is also a Boolean combination of events that is de-tected by the match unit comparators. However, the storage qualification condition differs from the trigger condition in that it evaluates trigger port match unit events to decide whether or not to capture and store each individual data sample. The trigger and storage qualification conditions can be used together to define when to start the capture process and what data to capture. In the ILA core example shown in Figure 3, suppose that the following operations are required:


Trigger on the first memory write cycle (CE = rising edge, WE = 1, OE = 0) to Ad-dress = FF0000h.

Capture only memory read cycles (CE = rising edge, WE = 0, OE = 1) from Address = 23AACCh and Data values between 00000000h and 1000FFFFh.

To implement these conditions, the TRIG0 and TRIG1 trigger ports should each have two match units attached to them, one for the trigger condition and one for the storage qualifi-cation condition. Table 1 summarizes the set up of the trigger condition and storage qualifica-tion equations and of each individual match unit, in order to satisfy the conditions stated in-itially ('R' means rising edge).

Table 1. The set up of trigger and storage qualification conditions for the example of Figure 3.

Trigger Condition: M0 && M2

M0[2:0] = CE:WE:OE = "R10" M2[23:0] = Address = "FF0000"

Storage Qualification Condition: M1 && M3 && M4

M1[2:0] = CE:WE:OE = "R01" M3[23:0] = Address = "23AACC" M4[31:0] = Data = in the range 00000000h ..1000FFFFh

2.2.2. Trigger Output Logic

The ILA core implements a trigger output port called TRIG_OUT. The signal on this port is the output of the trigger condition that is set up at run-time using the analyzer. The shape (level or pulse) and sense (active-High or active-Low) of the trigger output can also be controlled at run-time. The TRIG_OUT port can be connected to a device pin in order to trigger external test equipment such as oscilloscopes and logic analyzers. The TRIG_OUT port of one core can also be connected to a trigger input port of another core in order to expand the trigger and data capture capabilities of the design.

2.2.3. Data Capture Logic

Each ILA core can capture data using on-chip Block RAM resources independently from all other cores in the design. Each ILA core can capture data using one of two capture modes: Window and N samples. In Window capture mode, the sample buffer can be divided into one or more equal-sized sample windows. This mode uses a Boolean combination of the individual trigger match unit events in order to collect enough data to fill a sample window. The N samples capture mode is useful for capturing the exact number of samples needed per trigger without wasting capture storage resources. This mode is similar to the Window capture mode except for two major differences:

The number of samples per window can be any integer N from 1 to the sample buffer size minus 1;

The trigger must always be at position 0 in the window.

2.2.4. Control and Status Logic

The ILA core contains a control and status logic that is used to manage the operation of the core. All logic necessary to properly communicate with the ILA core is implemented by this control and status logic.


2.3. VIO Core

The Virtual Input/Output (VIO) core is a customizable core that can monitor and drive internal FPGA signals in real time. Unlike the ILA core, no storage resources are re-quired. There are four types of signals available in a VIO core:

Asynchronous inputs. These signals are sampled using the JTAG clock signal pro-vided by the JTAG cable. The input values are read back periodically and displayed in the graphical interface of the analyzer.

Synchronous inputs. These signals are sampled using the design clock signal. The input values are read back periodically and displayed in the graphical interface of the analyzer.

Asynchronous outputs. These signals are defined by the user in the graphical inter-face of the analyzer and driven out of the core to the surrounding logic. A logical 1 or 0 value can be defined for individual asynchronous outputs.

Synchronous outputs. These signals are defined by the user in the graphical interface of the analyzer, synchronized to the design clock signal, and driven out of the core to the surrounding logic. A logical 1 or 0 can be defined for individual synchronous out-puts.

Every VIO core input has additional cells to capture the presence of transitions on the input. Since the design clock will most likely be much faster than the sample period of the analyzer, it is possible for the signal being monitored to transition many times between suc-cessive samples. The activity detectors capture this behavior and the results are displayed along with the signal value in the graphical interface of the analyzer. In the case of a syn-chronous input, activity cells capable of monitoring for asynchronous and synchronous events are used. This feature can be used to detect glitches as well as synchronous transitions on the synchronous input signal. Every VIO core synchronous output has the ability to output a static 1, a static 0, or a pulse train of successive values. A pulse train is a 16-clock cycle sequence of 1 and 0 bits that drive out of the core on successive design clock cycles. The pulse train sequence is defined in the analyzer and is executed only one time after it is loaded into the core.

3. The ChipScope Core Inserter Tool ChipScope Core Inserter is a tool used after the synthesis process to generate a netlist that includes the user design, as well as the ICON and ILA cores needed. This tool enables to use the debug functionality in a simple manner to analyze an already synthesized design, without any instantiation of components into the source code. Projects saved with the Core Inserter tool keep all relevant information about source files, destination files, core parameters, and core settings. This allows storing and retrieving information about core insertion between sessions. The project file (with .cdc extension) can be used as an input to the analyzer to import signal names. When the associated top-level design is implemented using the ISE implementation tools, the cores are automatically inserted into the design netlist as part of the Translate process. There is no need to set any properties to enable this operation. The .cdc file that is included into the project is associated with the design module being implemented and causes the cores to be inserted automatically. The Core Inserter tool automatically reloads the design netlist if it detects that the netlist has changed since the last time it was loaded.

4. The ChipScope Analyzer Tool The ChipScope Analyzer tool interfaces directly to the ICON, ILA, and VIO cores. With this tool, the user can configure the FPGA device, set up trigger conditions, and view


the design signals in graphical form. The analyzer provides an intuitive interface to determine the functionality of the design. The ChipScope Analyzer tool consists of two distinct applications: the server and the client. The server is a console application that connects to the JTAG chain of the FPGA de-vice using a JTAG download cable. The client is a graphical user interface (GUI) application that allows interacting with the devices in the JTAG chain and the cores that are found in those devices. The server and client applications can be running on the same computer (local mode) or on different computers (remote mode). Remote mode is useful when the user needs to de-bug a system that is in a different location or to share a single system resource with other de-sign team members. If the user desires to debug a system that is connected directly to its local computer via a JTAG download cable, there is no need to start the server manually. The server applica-tion has to be started manually only when the user desires to interact with the server from a remote client. The server application can handle only one client connection at a time. The graphical interface of the client application consists of four parts:

Project tree: contains a graphical representation of the JTAG chain and the cores in the devices that are in the chain;

Signal window: displays all the signals for the core selected in the project tree;

Message pane: displays a list of status messages.

Main window: displays multiple windows (such as Trigger Setup, Waveform, Listing) at the same time.

Projects hold important information about the analyzer program state, such as signal names, signal ordering, bus configurations, and trigger conditions. They allow to conveniently store and retrieve this information between analyzer sessions.

5. Example Design This section presents the steps required to create and add an ICON core, an ILA core, and a VIO core to a simple design of a bidirectional 32-bit counter. The method of using the CORE Generator software for creating the ChipScope cores and adding them to the design is described. Next, the use of the ChipScope Analyzer software is presented.

5.1. Generating the ChipScope Cores In order to generate the ChipScope ICON, ILA, and VIO cores, first a CORE Genera-tor project has to be created.

5.1.1. Creating a CORE Generator Project

Perform the following steps to create a new CORE Generator project.

1. Launch the CORE Generator program (Start All Programs Xilinx ISE Design Suite 12.4 ISE Design Tools Tools CORE Generator).

2. In the window of this program, select File New Project. The New Project dialog window will open. Browse to the folder where the project has to be created (this should be a subfolder of the D:\Student\ folder). Create a new folder with the Create New Folder button, enter its name, click on the Open button, and then click on the Save button to save the coregen.cgp file to this folder. The ChipScope cores will be generated in this folder.

3. In the Part tab of the Project Options dialog window, select the type of FPGA device for which the cores should be generated. In the Family field select Spartan3E, in the


Device field select xc3s500e, in the Package field select fg320, and in the Speed Grade field select 4. Click on the OK button to close the window.

4. In the left part of the CORE Generator window, select the View by Function tab if it is not already selected. Expand the Debug & Verification section, and then expand the ChipScope Pro section. The list of available cores will be displayed. Among them should be the ICON, ILA, and VIO cores.

5.1.2. Generating the ICON Core

The ICON core controls the other ChipScope cores, such as ILA and VIO, through control ports. Perform the following steps to generate the ICON core.

1. In the left part of the CORE Generator window, double-click on the ICON (ChipS-cope Pro Integrated Controller) line. A window that allows setting the parameters of the ICON core opens.

2. In the Component Name field, enter a simpler name for the core, for instance, icon_01.

3. In the Number of Control Ports field, select the correct number of control ports for the ICON core. Each control port generated must be later connected to an ILA or VIO core to be possible synthesizing the design. Each ILA or VIO core requires one con-trol port. In this example design, one ILA core and one VIO core will be used. There-fore, select 2 for the number of control ports.

4. Leave the other options unselected, as in Figure 4, and click on the Generate button to create the ICON core files. While the core is generated, a progress indicator will ap-pear. After the ICON core has been generated, a list of files created will be displayed in a separate window. Click on the Close button to close this window.

Figure 4. Dialog window for setting the parameters of the ICON core.

5.1.3. Generating an ILA Core

An ILA core allows capturing and storing the values of selected signals within a hardware module when a certain trigger condition is satisfied. Perform the following opera-tions to generate an ILA core.


1. In the left part of the CORE Generator window, select the View by Function tab if it is not already selected.

2. Double-click on the ILA (ChipScope Pro Integrated Logic Analyzer) line. A win-dow that allows setting the parameters of the ILA core opens.

3. In the Component_Name field, enter a simpler name for the core, for instance, ila_01.

4. In the Number Of Trigger Ports field, select the required number of trigger ports for the ILA core. Each ILA core can have up to 16 separate trigger ports. Normally, a single trigger port is needed, so that leave unchanged the default setting of 1 for the number of trigger ports.

5. Leave the Use RPMs option selected. Therefore, Relationally Placed Macros (RPMs) will be used to improve the performance of the core.

6. Leave the Sample On field with the default Rising setting. This way, the rising edge of the clock signal will be used to capture the values of signals.

7. The Sample Data Depth field allows selecting the number of samples the ILA core will capture and store when the trigger condition is satisfied. One sample will be cap-tured in each clock cycle. The maximum number of samples captured depends on the number of available Block RAM (BRAM) units in the FPGA device. For this exam-ple design, leave the default value of this field (512) unchanged.

8. Unselect the Data Same As Trigger option. Therefore, the data port of the ILA core will be independent of its trigger ports. This allows to limit the amount of data that will be captured. If this option is unselected, the Data Port Width parameter needs to be specified. Enter the value 18 for this parameter.

9. Leave the other parameters with their default settings, as in Figure 5, and click on the Next button to display the window that allows setting the options for the trigger port.

Figure 5. First page of the dialog window for setting the parameters of the ILA core.

10. The Trigger Port Width field specifies the number of bits that will be used for the trigger condition. Leave this number with its default value of 8.


11. The Match Units field specifies the number of match units connected to each trigger port. A match unit is a comparator used to detect events on the trigger port it is con-nected to. When several match units are used, the results from these units are com-bined together to form the overall trigger condition. This allows a more flexible trig-ger condition equation, at the expense of more logic resources used. Select the value 2 for the number of match units.

12. Leave the Counter Width option with its Disabled setting. Therefore, the counter pro-vided at the output of each match unit will not be used. This counter might be confi-gured at run time to count a specific number of match unit events.

13. In the Match Type field, select extended (Figure 6). This allows to use more functions to specify the trigger conditions, such as >, ,


4. Select the Enable Synchronous Input Port option. This option allows connecting out-put signals from the design to the inputs of the VIO core. These signals should be synchronous to the clock signal of the VIO core. The number of signals is specified in the Width field. Leave the contents of this field to the default value of 8.

5. Select the Enable Synchronous Output Port option. This option allows connecting output signals from the VIO core to the inputs of the design, if these signals are syn-chronous to the clock signal of the VIO core. The number of signals is specified in the Width field. Change the contents of this field to 2.

6. Leave the Invert Clock Input option unselected (Figure 7). This option can be used to complement the clock signal that is connected to the input of the VIO core.

Figure 7. Dialog window for setting the parameters of the VIO core.

7. Click on the Generate button to create the VIO core files. A progress indicator will appear while generating the core. After the VIO core has been generated, a list of files created will be displayed in a separate window. Click on the Close button to close this window.

8. Close the CORE Generator window.

5.2. VHDL Description of the Example Design The example design consists of a 32-bit counter module and a main module contain-ing the instantiation of the counter. The VHDL description of the 32-bit counter is presented below. The direction of counting is controlled with the down signal. When this signal is as-serted, the counter is decremented, and otherwise the counter is incremented at each rising edge of the clock signal. library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_unsigned.all; entity count32 is port (clk : in std_logic; rst : in std_logic; down : in std_logic; count : out std_logic_vector(31 downto 0)); end count32; architecture Behavioral of count32 is


signal c_int : std_logic_vector(31 downto 0); begin process (clk, rst) begin if (rst = '1') then c_int '0'); elsif (clk'event and clk = '1') then if (down = '1') then c_int count); end Behavioral;

5.3. Creating the ISE Project

Launch the Project Navigator software of the Xilinx ISE Design Suite design envi-ronment and create a new project. In the Device Properties dialog window, select the type of FPGA device for which the project is created. In the Family field select Spartan3E, in the Device field select XC3S500E, in the Package field select FG320, and in the Speed field se-lect 4. After finishing to create the project, select File New or click the New button. In the New dialog box, select Text File, then select the OK button. Copy the VHDL descrip-


tion of the counter to the editor window and save the contents of the window to a file with the .vhd extension. Add to the project the file with the description of the counter. Perform the same operations to create a .vhd file for the main module and to add it to the project. In the Sources window, select the VHDL file of the main module. In the Processes window, double-click the Implement Design process to synthesize and implement the design. Correct any possible errors before continuing with the next steps.

5.4. Adding and Connecting the ChipScope Cores

After generating the ICON, ILA, and VIO cores, they have to be instantiated in the main module and connected to signals.

5.4.1. Adding and Connecting the ICON Component

Perform the following operations to instantiate and add the ICON component to the design.

1. In the Project Navigator main window, select File Open or select the Open button. Browse to the folder in which the CORE Generator project has been created, select the file with the name of the ICON core and the .vho extension (for instance, icon_01.vho), and then select the Open button.

2. Copy the component declaration of the ICON module from the .vho file and paste it into the declarative part of the main module, after the component declaration of the 32-bit counter and before the begin keyword.

3. Copy the instantiation template of the ICON component from the .vho file, paste it in-to the main module after the instantiation of the count32 component, and change the instance name of the ICON component.

4. Insert the declaration of two signals, control0 and control1, after the declaration of the count signal. These two control signals should have the same widths as the two ports of the ICON component.

5. Close the .vho file of the ICON module.

5.4.2. Adding and Connecting the ILA Component

In order to instantiate and add the ILA component to the design, perform the steps described below.

1. Select File Open or select the Open button. Browse to the folder in which the CORE Generator project has been created, select the file with the name of the ILA core and the .vho extension (for instance, ila_01.vho), and then select the Open but-ton.

2. Copy the component declaration of the ILA module from the .vho file and paste it to the declarative part of the main module, after the component declaration of the ICON module.

3. Copy the instantiation template of the ILA component from the .vho file, paste it into the main module after the instantiation of the ICON component, and change the in-stance name of the ILA component. Change the name of the signal connected to the CONTROL port of the ILA component to control0.

4. Insert the declaration of two signals, data and trig0, after the declaration of the control1 signal. These two signals connected to the data and trigger ports of the ILA component should have the same widths as the corresponding ports of the ILA component.


5. In the main module, after the assignment to the cnt_out signal, assign values to the data and trig0 signals. Assign to the data signal the signal obtained by concate-nating the down, rst, and bits 15..0 of the count signal. Therefore, the down and rst signals will be connected to bits 17 and 16 of the ILA modules data port, respec-tively. Assign to the trig0 signal bits 7..0 of the count signal.

6. Close the .vho file of the ILA module.

5.4.3. Adding and Connecting the VIO Component

In order to instantiate and add the VIO component to the design, perform the steps described below.

1. Select File Open or select the Open button. Browse to the folder in which the CORE Generator project has been created, select the file with the name of the VIO core and the .vho extension (for instance, vio_01.vho), and then select the Open but-ton.

2. Copy the component declaration of the VIO module from the .vho file and paste it into the declarative part of the main module, after the component declaration of the ILA module.

3. Copy the instantiation template of the VIO component from the .vho file, paste it into the main module after the instantiation of the ILA component, and change the in-stance name of the VIO component. Change the name of the signal connected to the CONTROL port of the VIO component to control1.

4. Insert the declaration of two signals, sync_in and sync_out, after the declaration of the trig0 signal. These two signals should have the same width as the corresponding ports of the VIO component.

5. In the main module, assign bits 31..24 of the count signal to the sync_in signal. Hence, the most significant 8 bits of the counter will be connected to the synchronous inputs of the VIO module.

6. Instead of connecting the rst and down signals of the 32-bit counter to buttons on the development board, we will connect these signals to bits 0 and 1 of the sync_out signal generated by the VIO module. This will allow setting the two signals using the graphical interface of the ChipScope logic analyzer. To make these connections, re-move the rst and down ports from the port list of the main module and declare rst and down as internal signals. Assign bit 0 of the sync_out signal to the rst signal and bit 1 of the sync_out signal to the down signal.

7. Close the .vho file of the VIO module.

8. Save the VHDL file of the main module.

5.5. Synthesizing and Implementing the Design

After adding the ICON, ILA, and VIO cores to the design and connecting them, the design can be synthesized and implemented using the XST synthesis tool. During the synthe-sis process, these cores will act as black boxes; their behavior will be provided during the implementation process in the form of netlists. Before synthesizing and implementing the design, create and add to the project an UCF file to specify the assignment of signals to the pins of FPGA device. To perform this, select File New to create a new text file. In the New dialog box, select Text File, and then select the OK button. Copy the following lines to the editor window and save the contents of the window to a file with .ucf extension. NET "clk" LOC = "C9" | IOSTANDARD = LVCMOS33;


NET "cnt_out" LOC = "F11" | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET "cnt_out" LOC = "E11" | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET "cnt_out" LOC = "E12" | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; NET "cnt_out" LOC = "F12" | IOSTANDARD = LVTTL | SLEW = SLOW | DRIVE = 8; Close the editor window of the UCF file and add this file to the project. Then perform the steps described below to synthesize and implement the design.

1. In the Sources window, select the VHDL file of the main module. In the Processes window, right-click on the Implement Design process and select the Process Proper-ties option. The Process Properties dialog window will open with the Translate Properties category selected. In the Value field of the Macro Search Path property, click on the button. In the Browse For Folder dialog window, browse to the folder in which the ChipScope core files have been generated, and then select the OK button. Close the Process Properties Translate Properties dialog window by selecting the OK button.

2. Specify the use of the JTAG clock for configuring the FPGA device. To perform this, in the Processes window right-click on the Generate Programming File process, and then select the Process Properties option. In the Process Properties dialog window select the Startup Options category, and for the FPGA Start-Up Clock property choose the JTAG Clock option. Close the Process Properties dialog window by se-lecting the OK button.

3. In the Processes window, double-click on the Implement Design process to synthesize and implement the design.

4. In the Processes window, double-click on the Generate Programming File process to generate the configuration file for the FPGA device.

5.6. Using the ChipScope Analyzer After generating the configuration file, the FPGA device on the development board can be configured either with the iMPACT tool or with the ChipScope Analyzer tool. In this example design, the ChipScope Analyzer tool will be used to configure the FPGA device. Af-ter that, it will be possible to set the trigger condition, to capture the values of selected signals, and to display the signal waveforms in graphical form. These operations are described next.

5.6.1. Configuring the FPGA Device

Perform the following steps to configure the FPGA device on the development board.

1. Connect a Spartan-3E development board to a USB port of the computer with a USB cable.

2. Connect the power supply to the board and move the power switch near the power connector to the ON position.

3. In the Processes window, double-click on the Analyze Design Using ChipScope process to launch the ChipScope analyzer. The ChipScope analyzer main window will open.

4. In the JTAG Chain menu select Xilinx Platform USB Cable even if it is already se-lected. The Platform USB Cable Parameters dialog box is displayed (Figure 8). Leave unchanged the default values that are selected and select the OK button.


Figure 8. Platform USB Cable Parameters dialog box.

5. In the message pane (at the bottom of the window) notice that the ChipScope tool tries to connect to the programming cable. If a Windows Security Alert dialog box ap-pears, ignore the message displayed and click on the OK button. If the cable connec-tion can be established, the Successfully opened Xilinx Platform USB Cable mes-sage will be displayed in the message pane. If the cable connection cannot be estab-lished, it is possible that the board drivers are not installed correctly or the drivers are not installed for the USB port used. In this case, connection to the cable should be tried again after properly installing the drivers or connecting to another USB port. When the connection is established, the JTAG Chain Device Order dialog box is dis-played (Figure 9), showing all the devices found in the JTAG chain. For the FPGA device, the Device Name field contains XC3S500E. Close the dialog box by selecting the OK button.

Figure 9. The JTAG Chain Device Order dialog box.

6. In the project tree (upper part of the left side of the window) right-click on the FPGA device name (XC3S500E) and select the Configure option from the menu. The JTAG Configuration dialog box opens. To select the configuration file, click on the Select New File button. The Open Configuration File dialog box opens. Browse to the ISE project folder, select the .bit configuration file, and click on the Open button to re-turn to the JTAG Configuration dialog box. Click on the OK button to configure the device.

7. If the configuration is performed successfully, the message INFO: Found 2 Core Units in the JTAG device Chain is displayed in the message pane and the rightmost four LEDs (LD3 .. LD0) on the board show that the counter is operational. The project tree is updated with the number of ChipScope cores detected on the device. The Trigger Setup, Waveform, Listing, and Bus Plot nodes appear under the ILA core, and the VIO Console node appears under the VIO core (Figure 10).

Figure 10. The project tree after configuring the FPGA device.


5.6.2. Using the VIO Core

To use the VIO core, the VIO Console window has to be opened. This window allows to observe the status and activity of the VIO core input signals and to modify the status of the VIO core output signals.

1. Double-click on the VIO Console node in the project tree to open the VIO Console window. In this window, the eight SyncIn signals are displayed in blue, and the two SyncOut signals are displayed in green.

2. The SyncIn input signals to the VIO core are connected to bits 31..24 of the counter. Rename each individual SyncIn[i] signal to the appropriate name count(j) of the counter signal. For instance, SyncIn[0] becomes count(24), and SyncIn[7] be-comes count(31). Renaming can be performed by right-clicking on the signal name, selecting the Rename option, and entering the new name into the Input dialog box.

3. The SyncOut[0] output signal from the VIO core is connected to the rst signal of the main module, while the SyncOut[1] signal is connected to the down signal of the main module. Rename these two SyncOut signals to their appropriate name.

4. The type of input signals to the VIO core can be set to LED, and therefore these sig-nals can simulate virtual LEDs of one of three colors (red, blue, or green). Set the type of count(24) .. count(27) signals individually to red LED by right-clicking on the signal name and selecting the options Type LED Red High. Similarly, set the type of count(28) .. count(31) signals to green LED. The VIO Console window will look like in Figure 11. The VIO core input signals are updated periodi-cally. Notice that the status of the green LEDs in the VIO Console window is the same as the status of the four LEDs that are used on the development board. The tran-sitions of the signals are also detected and are shown by arrows. These arrows are displayed in black because the signals are synchronous; in case of asynchronous sig-nals, the arrows would be displayed in red.

Figure 11. The VIO Console window after setting the type of input signals to LED.

5. Set the type of the rst output signal to Push Button to simulate a push button on the board (right-click on the signal name and select the options Type Push Button High). Click on the Value field of this signal and notice that the counter is reset.

6. Set the type of the down output signal to Toggle Button to switch between 1 and 0 with a single click (right-click on the signal name and select Type Toggle Button). Click on the Value field of this signal and notice that the direction of the counter is reversed.

7. Close the VIO Console window.


5.6.3. Setting the Trigger Condition

In order to capture the values of signals, first the trigger condition must be set up. This condition can be modified at run-time without the need to re-synthesize the design. In this example design, the eight least significant bits of the counter are connected to the trigger port of the ILA core. Perform the following steps to set up the trigger condition.

1. Double-click on the Trigger Setup node in the project tree to open the Trigger Setup window. This window has three sections: Match Functions, Trigger Conditions, and Capture Settings.

2. First, define the match functions. A match function specifies the trigger value for a

particular match unit. Maximize the Match Functions section with the Maximize button. The two match units used in this design are M0 and M1.

3. For the M0 match unit, in the Function field select the > function and change the con-tents of the Value field to 0000_0001.

4. For the M1 match unit, in the Function field select the < function and change the con-tents of the Value field to 0000_0100.

5. Collapse the Match Functions section by clicking on the vertical bar on the left side of this section.

6. Next, define the overall trigger condition that will be used by the core to capture the values of signals. This condition can be based on a Boolean equation or sequence of one or more match functions. Several trigger conditions can be defined, but only one condition can be active at any one time. Maximize the Trigger Conditions section

with the Maximize button. The single trigger condition that is available initially is displayed in this section, and it is set to the Active value by default.

7. The Trigger Condition Equation field displays the current trigger condition. Initially, only the M0 match unit is enabled. Click on M0 in the Trigger Condition Equation field to open the Trigger Condition dialog window. This window displays a table of all available match units. Click on the Enable field of the M1 match unit to enable it. The trigger condition equation will be set to M0 && M1 by default (Figure 12). It is possible to combine the outputs of match units with an OR logical operation, to ne-gate the output of any match unit individually, and to negate the overall equation. Leave unchanged the trigger condition equation and select the OK button to close the Trigger Condition dialog window.

8. Collapse the Trigger Conditions section by clicking on the vertical bar on the left side of this section.

9. Finally, in the Capture Settings section define the number of samples to capture, the number of capture windows, and the position of the trigger in those windows. A cap-ture window is a contiguous sequence of samples containing a single trigger event. Keep the default type of Window for the capture windows. In this case, the number of samples in each window must be a power of two and the triggering can occur in any position in the window. The Windows field specifies the number of capture win-dows. The Depth box defines the depth of each capture window. The Position field defines the position of the trigger in the windows. The Storage Qualification field can specify to capture each data sample (by default) or only samples that satisfy a Boo-lean AND or OR combination of all the enabled match units outputs. Keep the de-fault settings for all these fields.


Figure 12. The Trigger Condition dialog window.

10. Save the settings made in the Trigger Setup window to a file that can be opened later in the current project or in other projects. To perform this operation, in the main ChipScope menu select the Trigger Setup Save Trigger Setup command. In the Save Trigger Setup As File dialog window that opens, browse to the desired folder, enter the name of the file (keeping the .ctj extension), and select the Save button. The settings can be retrieved later and loaded into the Trigger Setup window by selecting the command Trigger Setup Read Trigger Setup.

5.6.4. Capturing Signals and Viewing the Waveforms

After setting up the trigger condition, the trigger can be armed to start capturing the values of selected signals. When the trigger condition is satisfied, the ILA core will start cap-turing the signals on the data port according to the capture settings until the sample buffer is full. The values of the signals are then sent to the computer via the downloading cable and are displayed in the Waveform window. Perform the operations described below to capture signals and display their wave-forms.

1. Double-click on the Waveform node in the project tree to open the Waveform window.

2. In the Bus/Signal column, click on the DataPort[0] signal, hold down the Shift key, and click on the DataPort[15] signal. After selecting these signals, right-click on any selected signal and choose the Move to Bus New Bus options. A new bus named DataPort will be created from the previously selected signals.

3. Right-click on the newly created bus, select Rename, enter count into the Input dialog box, and click on the OK button.

4. Rename the DataPort[16] signal to rst and the DataPort[17] signal to down. 5. In the main ChipScope window, click on the Trigger Now button. The ILA core

will ignore the trigger condition and storage qualification condition and will trigger the capturing immediately using a single capture window with the trigger position set to sample 0. When the sample buffer is full, the trigger disarms and the signals are displayed in the Waveform window. Right-click on the waveform of the count signal


and select the Zoom Zoom In option repeatedly until the counter value is visible (Figure 13).

6. To arm the trigger, click on the Run button. When the trigger condition is satis-fied, the Waveform window is updated with the newly captured signals. Notice that the least significant 8 bits of the count signal are either 02h (when the down signal is 0) or 03h (when the down signal is 1) at clock cycle position 0.

7. In the Capture Settings section of the Trigger Setup window, enter the value 10 into the Position field. Arm the trigger again and notice that in the Waveform window the signal waveforms start with 10 samples before the trigger event.

8. Disarm the trigger by clicking on the Stop Acquisition button. Close the ChipScope window and move the power switch of the board to the OFF position.

Figure 13. The Waveform window after the Trigger Immediate command.

6. Applications 6.1. Answer the following questions:

a. What are the advantages of using the ChipScope analyzer versus using a tra-ditional logic analyzer to debug hardware designs implemented in FPGA de-vices?

b. What are the main functions of the ICON, ILA, and VIO ChipScope cores?

c. What is a trigger condition?

d. What is a storage qualification condition?

6.2. Perform the steps described in Section 5 to design and analyze the operation of a bidirectional counter.

6.3. Modify the design of the multiplier circuit that uses the shift-and-add method (described in the Sequential-Arithm.pdf document) in order to implement the circuit on the Spartan-3E development board. First, in the main module of this circuit replace the SSEG and AN output ports with the A and Q output ports of four bits each. These ports will be connected to the LEDs on the board (the A port will be connected to LEDs LD7..LD4, and the Q port will be connected to LEDs LD3..LD0). Remove the TERM output port and declare TERM as an internal signal. Then remove the display and hex2sseg modules from the project and delete the instantiation of the display component from the main module. Connect the output signals of the A and Q registers to the A and Q output ports. Remove the UCF file from the project and instead of it add the mult_spartan3e.ucf constraints file, available in the mult_spartan3e.zip archive. Perform the synthesis and implementation of the design, correct-ing the possible errors.

6.4. Add to the project made for Application 6.3 the ChipScope cores needed for ge-nerating the input signals X and Y with a VIO core and for viewing all the internal signals of the circuit with the ChipScope analyzer. First, launch the CORE Generator software and change the parameters of the ILA and VIO cores generated for the example design so that the port widths will be sufficient. Then, in the main module of the multiplier circuit remove the X and Y input ports. Define internal signals in the place of these ports, signals that will be gen-erated with the VIO core. Instantiate the ChipScope cores in the main module and make the


required connections. Perform the synthesis and implementation of the design, correct the possible errors, and then follow the operation of the circuit with the ChipScope analyzer.

Date post:	07-Sep-2015
Category:	Documents
Upload:	asim-rafiq-janjua
View:	14 times
Download:	2 times

GOOD ChipScope e

Documents