Getting Started With the Nios II DPX Datapath Processor ---Version

Transcription

1 Getting Started With the Nios II DPX Datapath Processor ---Version This tutorial teaches you how to develop a complete system employing Altera event-driven datapath processing. In this tutorial, you create a Qsys system with a single Nios II DPX datapath processor, generate software for the processor, download and debug the software on hardware as well as perform RTL simulation in ModelSim. In this tutorial, you work with the Nios II DPX Simple Packet Processing design example. This tutorial also introduces some customizable System Console Tcl scripts that provide visual, non-intrusive monitoring of the Nios II DPX system at run time. This section describes preparation you need to perform before starting this tutorial. Prerequisite Knowledge This section assumes usage familiarity with the following tools: Altera Quartus II software Altera Qsys software Hardware and Software Requirements This tutorial requires the following hardware and software: Stratix IV GX FPGA Development Kit (DK-DEV-4SGX230N) Quartus II software v11.0 Nios II Embedded Design Suite (EDS) v11.0 Talkback must be enabled Installing the Simple Packet Processing Design Example The Nios II DPX Simple Packet Processing design example is an integral part of this tutorial. The design example shows how you can apply many useful techniques to a working Nios II DPX system. This section describes how to install the design example. This tutorial provides screen shots to help you follow the instructions. The screen shots were captured with v10.1 of the Quartus II software and Nios II EDS. If you are using a newer version of the software, your screen may differ from the screen shots. You can find the Nios II DPX Simple Packet Processing design example on the Packet-Processing Design Example Using Nios II DPX Datapath Processor page of the Altera website. Subscribe 2011 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX ar e Reg. U.S. Pat. & Tm. Off. and/ or trademarks of Altera Corporation in the U.S. and other countries. All other trademarks and service marks are the property of their respective holders as described at common/ legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera s standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. 101 Innovation Drive San Jose, CA

2 Page 2 The contents of the design example file unzip in a directory named nios2dpx_spp_4sgx230. This is your working directory. The path to your working directory must not contain spaces. The working directory's structure is shown in Figure 1. Figure 1. Working Directory Contents The design example folder includes the following files and directories: nios2dpx_spp_4sgx230.qpf This is the Quartus II project file. Nios2DPX_example_system_top.qsys This is a top-level system that instantiates the Nios II DPX datapath processor system and provides clock and reset management. Nios2DPX_example_system.qsys This is the Nios II DPX project file. This Qsys system is a subsystem within the top-level system. nios2dpx_spp_4sgx230.sdc This is the timing constraints file for the project. nios2dpx_spp_4sgx230.qsf This is the Quartus II project settings file. wave.do Waveform file for Simulation. ip This directory contains custom components used for this tutorial. software This directory contains software files for the Nios II DPX datapath processor. pll This directory contains an instance of the Altera PLL megafunction, used in the design. The completed_design directory under the working directory contains a fully completed tutorial design that can be used as a reference.

3 Page 3 Enabling Features and Modifying IP Search Path In v11.0, the Nios II DPX datapath processor is available as a hidden feature. The following steps make the processor visible in the Qsys component library. Also, the Simple Packet Processing design example includes custom processing elements and reset-management components. The following steps also add the custom components to the Qsys IP search path. 1. Start the Quartus II software. 2. Enable Talkback to provide access to Internal Features in Qsys. a. Select Options -> General -> Internet Connectivity b. Click Talback Options c. Enable Talkback 3. On the File menu, click Open Project. 4. Browse to your working directory and open nios2dpx_spp_4sgx230.qpf. The Quartus II project for the tutorial opens. 5. On the File menu, click Open. 6. Browse to your working directory and open Nios2DPX_example_system.qsys. This step starts Qsys. 7. In Qsys, on the Tools menu, click Options. 8. Click Internal in the Category pane. 9. Turn on Enable Internal Features. 10. Click Finish. 11. In the Component Library pane of Qsys, right-click Project. 12. In the right-click menu, click Show Hidden Components, as displayed in Figure 2. Figure 2. Show Hidden Components

4 Page Under Library, expand Processors. This list contains the Nios II DPX Datapath Processor component as displayed in Figure 3. Figure 3. Nios II DPX Datapath Processor in Qsys

5 Page 5 Description of the Simple Packet Processing Design Example Overview The Nios II DPX Simple Packet Processing design example mimics what a forwarding router might do when it receives TCP or UDP packets from an external interface. Figure 4 shows the Ethernet packet-processing flow that this design example implements. For simplicity, it is assumed that all frames received are valid Ethernet frames and that the processing is to be performed only for IPv4 datagrams carrying TCP or UDP. Figure 4. Ethernet Packet-Processing Flow The system receives frames from an external interface such as a wide-area network (WAN) and must fetch local network destination information so that the received Ethernet frame can be routed to the appropriate local network interface.

6 Page 6 On receiving a frame, the system is expected to perform the following steps: 1. Determine whether the frame is a valid Ethernet II Internet Protocol (IP) version 4 frame. If not, the frame is discarded. 2. An IP frame might arrive in fragments. If the frame is an IP fragment, it is discarded for simplicity. 3. If the IP frame is not a TCP or UDP protocol type, it is discarded. 4. The system must fetch local IP address and port information using the source and destination IP address and port information in the packet. In practice, this step would involve performing a lookup operation. 5. Using the local destination IP address from Step 4, obtain the corresponding network interface MAC address. This step would also involve performing a lookup operation. 6. Update the received Ethernet frame information to replace the destination IP address, port and MAC address with the resolved information. A virtual LAN (VLAN) tag is inserted. Additionally the time to live (TTL) value is decremented and the IP field checksum value is recalculated and replaced. 7. Forward the Ethernet frame on to the local network. Design Partitioning The Nios II DPX datapath processor provides processing capability in an event-driven framework. It is designed to work in conjunction with other processing elements (PEs) for high-performance event-driven processing and requires an input PE that accepts system input and generates the first event specific to the input context. Figure 5 shows the design example partitioned into PEs. The processing flow is divided amongst the following PEs, one of which is a Nios II DPX datapath processor: Input PE The input PE implements filtering to accept only valid Ethernet frames. Nios II DPX datapath processor The Nios II DPX datapath processor is a specialized PE, whose functionality is implemented in software, making it easier to modify than functionality implemented in RTL. The protocol-specific checks (such as checking for IPv4 and IPv4 information, such as fragments, TCP or UDP) are implemented as software on the Nios II DPX datapath processor. The processor also computes the IP checksum. Custom PE-1 and Custom PE-2 These processing elements model the described lookup operations. Depending on the complexity, lookup operations might benefit from hardware acceleration and therefore are implemented as custom processing elements in this design. Output PE The output PE replaces header information as it pulls the frame from the FIFO for forwarding onto the local network. The output PE can do this replacement efficiently because the input PE stores the received frame in a FIFO that is accessible to the output PE.

7 Page 7 Figure 5. Design Partitioning

8 Page 8 Figure 6 illustrates the processing of a single Ethernet frame across the various processing elements: Figure 6. Packet Processing Across Processing Elements The context ID (CID) order enforcement stage ensures that when the Nios II DPX datapath processor sends PE messages to the output PE, all contexts are in the correct order, regardless of the processing sequence in earlier stages. Order enforcement is required because the frames accepted by the input PE are stored in a FIFO that is used by the output PE. Design Implementation Hardware Design Implementation Figure 7 shows the hardware implementation for the Nios II DPX Simple Packet Processing design example. The required clock and reset management structure is not shown in this diagram. The standard components included with Quartus II are: Nios II DPX datapath processor LED and Button PIOs Data memory Processing Element Message Switch Avalon-ST FIFO JTAG to Avalon Master Clock-crossing bridge

9 Page 9 Figure 7. Hardware Design

10 Page 10 The other components are custom messaging blocks and are included in the design files. These components are as follows: Input PE The input processing element (PE) accepts a valid Ethernet frame and generates an event for the Nios II DPX datapath processor. On accepting a frame, it obtains a CID from the Nios II DPX datapath processor and transfers the frame's header information into Nios II DPX datapath processor's input context registers. It generates a PE message with task ID set to TID_NEW_PACKET_TASKID (0) and sends it to the Nios II DPX datapath processor that has a PEID of zero. It stores the accepted frame in a FIFO that is accessible to the output PE and places the first 64 bytes of Ethernet frame data in input context registers CRi[0] through CRi[15]. Example PE-1 and example PE-2 These two PEs emulate a lookup on PE message data received from the datapath processor. These PEs perform the following actions: Receive data from the Nios II DPX datapath processor in data arguments. Generate a hash of all received input arguments, and return the hashed value over the configured number of transmit arguments. The task ID for the generated message is the same as the received message's task ID. In this example, task IDs TID_LOOKUP_LOCAL_IP_AND_PORT and TID_LOOKUP_LOCAL_MAC (16 and 17) are used for the two lookup event messages. The example PE blocks have Avalon slave interfaces that connect to a JTAG to Avalon master component. This interface allows you to control and monitor the example PE blocks from System Console. Output PE The output PE receives a message from the Nios II DPX datapath processor. This message controls how it reads the Ethernet frame from the FIFO, replaces or inserts information read from the Nios II DPX output context register interface, and outputs the edited frame. The following operations are performed: Receives packet edit instructions, such as to discard the frame or replace the frame contents Edits the Ethernet frame if the message contains an edit instruction. Generates a message, with task ID TID_PROCESS_FRAME_DATA (32), to the Nios II DPX datapath processor. This message indicates that it is finished with the frame, and with any related resources indexed by the context ID. Therefore the context ID can be freed. Stimulus Block This block emulates a network connection. It provides valid Ethernet frames to the input PE and accepts frames that it receives from the output PE. The stimulus block generates Avalon streaming (Avalon-ST) packets that are separated in time. This separation is the inter-packet gap (IPG). The stimulus block has an Avalon-MM slave interface that is connected to a JTAG to Avalon Master Component, allowing System Console to set the IPG value. Example Components The design package contains sources for all the example components. Figure 8 shows the contents of the ip folder, in the working directory. Figure 8. ip Directory Content

11 Page 11 example_pe This directory contains the example PE source files. input_pe This directory contains the input PE source files. output_pe This directory contains the output PE source files. temp_stim_gen This directory contains the stimulus generator source files. example_reset_mgmnt This directory contains sources files for a possible Nios II DPX reset management. Refer to the Nios II DPX Datapath Processor Handbook for reset sequencing requirements. Nios II DPX Datapath Processor Software The Nios II DPX datapath processor instantiated in this design is a single-core processor and therefore has eight hardware threads. Thread 0 is used for visual operational indication. It blinks LEDs periodically. Threads 1 through 7 are involved in packet processing. The software implementation consists of four functional tasks, implemented in the pp.c source file, as explained below: _new_packet_entry_() This task's ID is zero. It is executed when the processor receives a message from the input PE. The input PE generates a PE message with task ID TID_NEW_PACKET_TASKID (0) when it receives a frame from the stimulus generator and stores information in the processor's input context registers. This task performs IPv4, TCP/UDP, fragmentation and checksum validity using the data stored in the Input context Registers. If the validation fails, it sends a PE message with CID ordering enforced to task ID TID_PROCESS_FRAME_DATA (32) on the output PE, instructing that the frame be discarded. If the validation passes, it sends a PE message with task ID TID_LOOKUP_LOCAL_IP_AND_PORT (16) to the local IP port lookup PE (example PE 1). _wan_to_local_lookup_result_() This task's ID is TID_LOOKUP_LOCAL_IP_AND_PORT (16). It is executed when the processor receives a message from example PE 1 with the results for local IP port lookup. This task stores the looked-up destination IP and port address into the output context registers. It then sends a PE message with the looked-up IP port information to example PE 2 with task ID TID_LOOKUP_LOCAL_MAC (17) to look up the corresponding MAC address. _MAC_lookup_result() This Task's ID is TID_LOOKUP_LOCAL_MAC (17). It is executed when the processor receives a message from example PE 2 with the MAC address lookup results. It stores the MAC address and other relevant information in the output context registers. This task checks the TTL value. If the TTL value has expired, it sends a message with task ID TID_PROCESS_FRAME_DATA (32) to the output PE to discard the frame. If TTL has not expired, it sends a message with the same task ID, TID_PROCESS_FRAME_DATA (32) to the output PE to process the frame data. The PE message is sent with CID ordering turned on because this is the final message in the processing sequence for a context. CID ordering ensures that the PE messages sent from this task are sent in order in which the CIDs were allocated, which represents the order in which the input PE received the frames. When the output PE receives this message, it either discards the frame or reads information from the output context registers of the processor. In the latter case, it replaces appropriate fields with the Ethernet frame, and forwards the packet to the local network interface, which is emulated by the stimulus generator. _return_ordered_cid_to_fifo_() This task's ID is TID_PROCESS_FRAME_DATA (32). This task runs in response to a PE message from the output PE. When a frame exits the system, and the context ID associated with the frame is no longer valid, the output PE sends a message to task ID TID_PROCESS_FRAME_DATA. When it receives this message, the _return_ordered_cid_to_fifo_() task generates a null PE message, with the free-cid message option enabled. On receiving this null PE message, the Nios II DPX message interface unit (MIU) discards the message and frees the CID.

12 Page 12 Stratix IV GX FPGA Development Board Resources This Nios II DPX Simple Packet Processing design example targets the Stratix IV GX FPGA development board, which is part of the Stratix IV GX FPGA Development Kit (DK-DEV-4SGX230N). The design is self-contained, using only the 50MHz clock to drive the phase-locked loop (PLL), a push-button input and 8 discrete LED outputs. The Nios II DPX datapath processor's thread 0 outputs a pattern periodically on the LEDs to provide a visual operational indication. Thread 0 also monitors the push-button input and changes the pattern if the button is pressed.

13 Page 13 Creating the Qsys System Overview This example system is composed of the following two Qsys systems, as shown in Figure 9: A top-level system that instantiates the Nios II DPX system and provides clock and reset management A Nios II DPX system that includes all the messaging components The top-level system is generic. Therefore you can use it as a container for your custom Nios II DPX system. This section starts by creating the Nios II DPX Qsys system and then the top-level Qsys system. Figure 9. Qsys System Composition

14 Page 14 Creating the Nios II DPX Datapath Processor System Figure 10 shows the Nios II DPX system that is created in this section. Figure 10. Nios II DPX Datapath Processor System

15 Page 15 The partially-completed Qsys system, Nios2DPX_example_system.qsys, contains the blocks colored in gray in Nios II DPX. The following sections guide you through the steps for instantiating the other components. Specifying the Qsys Components For this step, open Nios2DPX_example_system.qsys if not already opened. The partially-completed Qsys system provided in your Quartus II project contains components that are not necessarily central to PE messaging design concept. This section takes you through the steps for adding the key components for completing the Qsys design. This section takes you through the process of adding PE messaging components and data memory that is used by Nios II DPX software. Adding the Nios II DPX Datapath Processor This design uses a single-core Nios II DPX datapath processor. 1. Under Library > Processors in the Qsys Component Library pane, double-click the Nios II DPX Datapath Processor component. The Nios II DPX datapath processor has the following configuration panes: Nios II DPX Datapath Processor Accept defaults for this tab. Multithreaded Processor Settings Select the Multithreaded Processor tab and configure the parameters as follows: Select Enable Variable Latency data master. You need this setting because the processor connects to peripherals that do not run at the speed of the processor and also those that do not have a two-cycle read latency. Set the Fixed Latency data master low address to 0x and the Fixed Latency data master high address to 0x7FFF. These settings force access to addresses outside the range to use the variable-latency data master port. The variable-latency peripherals are located outside this range.

16 Page 16 Table 1 lists the values for this tab's parameters. Table 1. Multithreaded Processor Tab Settings Parameter Value Custom reset/exception/debug vector offsets Custom exception address offset Exception address Custom break address offset Break address Custom reset address offset Reset address Disabled 0x00001FFC 0x80001FFC 0x00001FF8 0x80001FF8 0x x Data Master Byte address bit width 16 Enable Variable Latency Data Master Fixed Latency Data Master Low Address Fixed Latency Data Master High Address Enable data master threadinfo interface Enabled 0x x00007FFF Disabled Message Interface Unit Accept the default settings on the Message Interface Unit tab. Memory Options (Advanced) Accept the default settings on the Memory Options tab. External Interfaces Accept the defaults on the External Interfaces tab. Advanced Options Accept the defaults on the Advanced Options tab.

17 Page 17 Debug Statistics This tutorial demonstrates system visualization by accessing the debug statistics. Enable all available statistics and debug counters, as shown in Table 4. Table 4. Debug Statistics Tab Settings Parameter Value Enable debug statistics Enable processor instruction counters Enable statistics for context ID Enable statistics for input Task ID Enable statistics for output task Enable statistics for task ticks Enable statistics for processing cycles on context ID 0 Enabled Enabled Enabled Enabled Enabled Enabled Enabled Enable statistics for free context ID FIFO Enabled Enable statistics for input task queue Enabled Enable statistics for output task queue Enabled Enable statistics for context ID reordering level Enabled 2. Click Finish Exporting Reset Request Signal The Nios II DPX datapath processor has a reset request signal, reset_request_n, that must be used for synchronizing the message reset and processor reset signals. Export this signal as nios2dpx_0_reset_request_n by clicking the Export column for the reset_request_n signal's row in Qsys. Adding the Input PE The input PE receives Ethernet frames from the stimulus generator. When it receives a frame, the input PE requests a CID from the Nios II DPX datapath processor and transmits a message to the datapath processor through the PE Message Switch. 1. Under Project > Nios2DPX Example Design Components in the Qsys Component Library pane, open the Example Input Processing Element component. 2. Configure the general parameters as follows: Set the input PE's PEID to 4.

18 Page 18 Set the Destination PE ID to 0. This directs the input PE to generate PE messages with the Destination PE ID set to 0, the Nios II DPX datapath processor. Set the Task ID on Destination PE field to 0. This directs the input PE to set the task ID of the messages it generates to zero. Set the NUM_CIDS value to 32, the maximum number of CIDs available from the Nios II DPX datapath processor. 3. Configure the stimulus generator interface as follows: ATL Channel width: 4 ATL error width: 1 4. Configure the input context register interface as follows: Set the Number of Context-In (CRi) registers to 16, which is the total input context registers per context configured on the Nios II DPX datapath processor. Configure the input context register interface's address width, CRI_IF_ADDR_WIDTH, to Configure the PE Message's Control word layout as follows: Control Word width (MSG_OUT_CONTROL_WORD_WIDTH): 33 Destination PE ID width (MSG_OUT_DST_WIDTH): 6 Task ID width (MSG_OUT_TID_WIDTH): 6 Source PE ID width (MSG_OUT_SRC_WIDTH): 6 Destination PE ID offset in the control word (MSG_OUT_DST_BASE): 25 Task ID offset in the control word (MSG_OUT_TID_BASE): 9 Source PE ID offset in the control word (MSG_OUT_SRC_BASE): 17 Context ID offset in the control word (MSG_OUT_CID_BASE): 1 6. Click Finish.

19 Page 19 Table 5Input PE Settings lists the configuration values for the input PE. Table 5. Input PE Settings Parameter Value PEID 4 Destination PE ID 0 Task ID on destination PE 0 NUM_CIDS 32 ATL_CHANNEL_WIDTH 4 ATL_ERROR_WIDTH 1 Number of Context In (CRi) Registers 16 CRI_IF_ADDR_WIDTH 12 MSG_OUT_CONTROL_WORD_WIDTH 33 MSG_OUT_DST_WIDTH 6 MSG_OUT_TID_WIDTH 6 MSG_OUT_SRC_WIDTH 6 MSG_OUT_DST_BASE 25 MSG_OUT_TID_BASE 9 MSG_OUT_SRC_BASE 17 MSG_OUT_CID_BASE 1 Adding an Example PE for Local IP Port Lookup This example PE serves as a local IP port lookup PE. The Nios II DPX datapath processor sends a message with two 32-bit data arguments to this example PE. On receiving a message, the example PE sends a message back with two different 32-bit data arguments, mimicking a local IP port lookup process. The latency between the received message and transmitted message can be controlled at run time and is initialized to three message-clock ticks. The IPG is also runtime configurable and is initialized to zero. 1. Under Project > Nios2DPX Example Design Components in the Qsys Component Library pane, double-click the Example Processing Element component. 2. Configure general Parameters as follows: The PE message's data Argument Width: 32.

20 Page 20 The Max number of arguments expected in a message: 8. The example PE's PE ID: Configure the general Message Interface configuration as follows: Width of PE ID Fields in the PE messages: 3 Task ID Width in the PE messages: 8 Flag width in the PE messages: 1 CID width in the PE messages: 5 4. Configure this example PE's latency modeling for the IP lookup process as follows: Maximum messages that this PE can receive without applying back pressure (Maximum supported messages): 32 Latency timer width: Configure Inter Packet Gap configuration: Minimum IPG enforcement counter width: Set the returned message's number of arguments to Configure the input PE s transmitted message control word layout as follows: Control Word Width: 33 Configure the offsets for fields in the Control word as follows: Destination PE ID (DST_ID): 25 Source PE ID (SRC_ID): 17 Task ID (TID): 9 Context ID (CID): 1 Flags: 0 8. Configure the input PE Message's received message's control word layout as follows: Control Word width: 33 Configure the offsets for fields in the Control word as follows: Destination PE ID (DST_ID): 25 Source PE ID (SRC_ID): 17 Task ID (TID): 9 Context ID (CID): 1 Flags: 0 9. Click Finish. 10. Rename the added component to Example_PE_1.

21 Page 21 Table 6 lists the Example_PE_1 configuration values. Table 6. Example_PE_1 Settings Group Parameter Value Argument Width 32 Parameters Max number of arguments 8 PE ID 1 Width of PE ID Fields 3 General Message interface Configuration Task ID Width 8 Flag width 1 CID Width 5 Latency modeling configuration Maximum supported messages 32 Timer Width 12 throughput (throttling) configuration Minimum IPG enforcement counter width 12 Returned message configuration Returned message number of arguments 2 Control Word width 33 Base Bit: DST_ID 25 Message Input Interface Base Bit: SRC_ID 17 Base Bit: TID 9 Base Bit: CID 1 Base Bit: flags 0 Control Word Width 33 Base Bit: DST_ID 25 Message Output Interface Base Bit: SRC_ID 17 Base Bit: TID 9 Base Bit: CID 1 Base Bit: flags 0

22 Page 22 Adding an Example PE for MAC Lookup This example PE serves as a MAC lookup PE. The Nios II DPX datapath processor sends a message with two 32-bit data arguments to this example PE. On receiving a message, the example PE sends a message back with two different 32-bit data arguments, mimicking a MAC lookup process. The latency between the received message and transmitted message can be controlled at run time and is initialized to three message-clock ticks. The IPG is also runtime configurable and is initialized to zero. 1. Under Project > Nios2DPX Example Design Components in the Qsys Component Library pane, double-click the Example Processing Element component. 2. Configure parameters as follows: The PE message's data Argument Width: 32. The Max number of arguments expected in a message: 8. The example PE's PE ID: onfigure the general Message Interface configuration as follows: Width of PE ID Fields in the PE messages: 3 Task ID Width in the PE messages: 8 Flag width in the PE messages: 1 CID width in the PE messages: 5 4. Configure this example PE's latency modeling for the IP lookup process as follows: Maximum messages that this PE can receive without applying back pressure (Maximum supported messages): 32 Latency timer width: Configure the Throughput Configuration: Minimum IPG enforcement counter width: Set the returned message's number of arguments to 2 7. Configure the Message Output Interface as follows: Control Word Width: 33 Configure the offsets for fields in the Control word as follows: Destination PE ID (DST_ID): 25 Source PE ID (SRC_ID): 17 Task ID (TID): 9 Context ID (CID): 1 Flags: 0 8. Configure the Message Input Interface as follows: Control Word width: 33 Configure the offsets for fields in the Control word as follows: Destination PE ID (DST_ID): 25 Source PE ID (SRC_ID): 17 Task ID (TID): 9

23 Page 23 Context ID (CID): 1 Flags: 0 9. Click Finish. 10. Rename the added component to Example_PE_2.

24 Page 24 Table 7Example_PE_2 Pa shows Example_PE_2 settings Table 7. Example_PE_2 Parameters Group Name Value Argument Width 32 Parameters Max number of arguments 8 PE ID 2 Width of PE ID Fields 3 General Message interface Configuration Task ID Width 8 Flag width 1 CID Width 5 Latency modeling configuration Maximum supported messages 32 Timer Width 12 throughput (throttling) configuration Minimum IPG enforcement counter width 12 Returned message configuration Returned message number of arguments 2 Control Word width 33 Base Bit: DST_ID 25 Message Input Interface Base Bit: SRC_ID 17 Base Bit: TID 9 Base Bit: CID 1 Base Bit: flags 0 Control Word Width 33 Base Bit: DST_ID 25 Message Output Interface Base Bit: SRC_ID 17 Base Bit: TID 9 Base Bit: CID 1 Base Bit: flags 0

25 Page 25 Adding the Output PE 1. Under Project > Nios2DPX Example Design Components in the Qsys Component Library pane, double-click Example Output Processing Element component. 2. Configure the General Message Interface properties as follows: Set the output PE's PE ID to 3. Set the CID Width in the control word to 5 Set the Flag width in the PE message's control word to 1 Set the User width in the PE message's control word to 0 3. Configure the General Module Properties as follows: Avalon Streaming channel width to Stimulus block (STR_OUT_CH_WIDTH): 4 Number of 32-bit output context registers (NUM_CR_OUT): 16 Output context register interface's read latency (CR_READ_LATENCY): 2 4. Configure the Received PE Message's Control word layout as follows: Control Word width (MSG_IN_CONTROL_WRD_WIDTH): 33 Destination PE ID width (MSG_IN_DST_WIDTH): 6 Source PE ID width (MSG_IN_SRC_WIDTH): 6 Task ID width (MSG_IN_TID_WIDTH): 6 Destination PE ID offset in the control word (MSG_IN_DST_BASE): 25 Source PE ID offset in the control word (MSG_IN_SRC_BASE): 17 Task ID offset in the control word (MSG_IN_TID_BASE): 9 Context ID offset in the control word (MSG_IN_CID_BASE): 1 5. Configure the Transmitted PE Message's Control word layout as follows: Control Word width (MSG_OUT_CONTROL_WRD_WIDTH): 33 Destination PE ID width (MSG_OUT_DST_WIDTH): 6 Source PE ID width (MSG_OUT_SRC_WIDTH): 6 Task ID width (MSG_OUT_TID_WIDTH): 6 Destination PE ID offset in the control word (MSG_OUT_DST_BASE): 25 Source PE ID offset in the control word (MSG_OUT_SRC_BASE): 17 Task ID offset in the control word (MSG_OUT_TID_BASE): 9 Context ID offset in the control word (MSG_OUT_CID_BASE): 1 6. Click Finish.

26 Page 26 Table 8 lists output PE settings. Table 8. Output PE Setting Parameter Value PE_ID 3 CID_WIDTH 5 FLAG_WIDTH 1 USER_WIDTH 0 STR_OUT_CH_WIDTH 4 NUM_CR_OUT 16 CR_READ_LATENCY 2 MSG_IN_CTRL_WRD_WIDTH 33 MSG_IN_DST_WIDTH 6 MSG_IN_SRC_WIDTH 6 MSG_IN_TID_WIDTH 6 MSG_IN_DST_BASE 25 MSG_IN_SRC_BASE 17 MSG_IN_TID_BASE 9 MSG_IN_CID_BASE 1 MSG_OUT_CTRL_WRD_WIDTH 33 MSG_OUT_DST_WIDTH 6 MSG_OUT_SRC_WIDTH 6 MSG_OUT_TID_WIDTH 6 MSG_OUT_DST_BASE 25 MSG_OUT_SRC_BASE 17 MSG_OUT_TID_BASE 9 MSG_OUT_CID_BASE 1

27 Page 27 Adding an Avalon-ST Pipeline Stage To improve design timing, add an Avalon-ST pipeline stage. This pipeline stage interfaces the Processing Element Message Switch to the output PE's PE message interface. The PE message interface from the Processing Element Message Switch is 65-bits wide, that is, a symbol is 65 bits wide, and the transfer rate is one symbol per beat of the message clock. 1. Under Library > Bridges and Adapters > Streaming in the Qsys Component Library pane, double-click Avalon-ST Pipeline Stage component. 2. Configure the component parameters as follows: Symbols per beat: 1 Bits per symbol: 65 Channel Width: 0 Maximum Channel Value: 0 Error width: 0 Turn on pipeline ready signal Turn on Use Packets 3. Click Finish. Table 9 lists the pipeline stage settings. Table 9. Avalon-ST Pipeline Stage Settings Parameter Value Symbols per beat 1 Bits per symbol 65 Channel width 0 Maximum channel value 0 Error width 0 Pipeline ready signal Use packets Use empty Enabled Enabled Disabled Empty width 0 Packet width 2

28 Page 28 Adding an Avalon-ST Single Clock FIFO Ethernet frames received by the input PE need to be buffered while the local IP port and MAC information is obtained. After this information is obtained, the output PE must replace the appropriate fields in the buffered Ethernet frame and forward it to the local network. This buffering of frames is done in an Avalon-ST single clock FIFO. The Ethernet frames from the stimulus generator are provided as a group of four bytes, that is, 32 bits wide. The FIFO must be able to hold at least a complete frame. So the FIFO is configured for a 32-bit word with a capacity for a maximum of 512 words. 1. Under Library > Memories and Memory Controllers > On-Chip in the Qsys Component Library pane, double-click Avalon-ST Single Clock FIFO component. 2. Configure component parameters as follows: Symbols per beat: 4 Bits per symbol: 8 FIFO Depth: 512 Channel Width: 0 Error Width: 0 Turn on Use packets 3. Click Finish. Table 10 lists Avalon-ST Single Clock FIFO setting. Table 10. Avalon-ST Single Clock FIFO Setting Parameter Value Symbols per beat 4 Bits per symbol 8 FIFO Depth 512 Channel width 0 Error width 0 Use Packets Use fill level Use Store and forward Use almost full status Use almost empty status Enabled Disabled Disabled Disabled Disabled

29 Page 29 Adding the Processing Element Message Switch The messaging components exchange messages through the Processing Element Message Switch. 1. Under Library > Message Interconnect in the Qsys Component Library pane, double-click Processing Element Message switch. 2. Configure the Packet Format as follows: Control word width: 33 Routing field base: 25 Routing field width: 3 Data argument width: Select Pipeline cross-connect and Pipeline arbitration. 4. Set the Number of message input ports to 5. There are five PE's that generate messages: input, output, two example PE's and the datapath processor. 5. Add four output ports to the Outgoing ports configuration table as shown in Processing Element Message Switch Settings. The routing field values correspond to the PE IDs of the datapath processor, example PE 1, example PE 2 and the output PE. 6. Click Finish.

30 Page 30 Figure 11. Processing Element Message Switch Settings

31 Page 31 Adding Nios II DPX Datapath Processor Peripherals The provided Qsys design contains an output PIO that interfaces with LEDs, an input PIO that interfaces with a single push button, and a JTAG UART. The Nios II DPX datapath processor accesses these peripherals over a pipelined bridge. The peripherals are used by software for debug status purposes. Nios II DPX software needs access to data memory. This design uses on-chip memory connected to the processor's fixed-latency data master port. 1. Under Library > Memory and Memory Controllers in the Qsys Component Library pane, double-click On-Chip Memory (RAM or ROM) component to add a single-port RAM memory. 2. Set the Slave s1 Latency to Turn on Initialize memory content. 4. Turn on Enable non-default initialization file. 5. Set User created initialization file to data_memory. 6. Click Finish. 7. Rename the component to data_memory. Table 11 lists the on-chip memory settings. Table 11. data_memory (On-Chip Memory) Setting Parameter Value Type Dual Port Access Read During Write Mode Block Type RAM (writable) Disabled DONT_CARE Auto Data Width 32 Total Memory size 4096 Minimize memory block usage (may impact fmax) Disabled Slave s1 Latency 2 Slave s2 Latency 1 Initialize memory content Enable non-default initialization file User created initialization file Enable In-System Memory Content Editor feature Instance ID Enabled Enabled data_memory Disabled NONE

32 Page 32 Specifying Clock Connections This Qsys system has three clock sources: processor clock (cpu_clk), PE messaging clock source (msg_clk) and debug clock source (dbg_clk). Connect the processor clock source to the components listed in Table 12. Table 12. Processor Clock Connections Clock Source Component Port cpu_clk.clk data_memory vldm_cdc mm_bridge_0 nios2dpx_0 clk1 clk_s1 clk cpu_clk

33 Page 33 Connect the message clock source to the components listed in Table 13. Table 13. Message Clock Connections Clock Source Component Port msg_clk.clk Example_PE_1 Example_PE_2 nios2_dpx_exdes_stim_0 vldm_cdc ex_design_control_master Jtag_uart_0 pe_msg_switch_0 pio_led pio_pb_in sc_fifo_0 clk_in clk_in clk_in clk_m1 clk clk clk clk clk clk context_in_clk nios2dpx_0 context_out_clk message_clk st_pipeline_stage_0 ex_nios2dpx_in_module_0 ex_nios2dpx_out_module_0 cr0 msg_clk msg_clk Connect the debug clock source to the components listed in Table 14. Table 14. Debug Clock Connections Clock Source Component Port dbg_clk.clk nios2dpx_0 debug_clk

34 Page 34 Specifying Reset Connections Before specifying reset connections, ensure that the Nios II DPX datapath processor's reset_request_n signal is exported as nios2dpx_0_reset_request_n. If necessary, click in the Export column in the signal's row, and accept the default export name. This Qsys system has three reset domains; processor clock domain reset, PE messaging clock domain reset and debug clock domain reset. Connect the processor clock domain reset to the components listed in Table 15. Table 15. Processor Clock Domain Reset Connections Reset Source Component Port cpu_clk.clk_reset data_memory vldm_cdc mm_bridge_0 nios2dpx_0 reset1 reset_s1 reset cpu_rst_n

35 Page 35 Connect the Message clock domain reset to the components listed in Table 16. Table 16. Processor Clock Domain Reset Connections Reset Source Component Port msg_clk.clk_reset Example_PE_1 Example_PE_2 nios2_dpx_exdes_stim_0 vldm_cdc Jtag_uart_0 pe_msg_switch_0 pio_led pio_pb_in sc_fifo_0 clk_reset clk_reset clk_rst reset_m1 reset clk_reset reset reset clk_reset context_in_rst_n nios2dpx_0 context_out_rst_n message_rst_n st_pipeline_stage_0 ex_nios2dpx_in_module_0 ex_nios2dpx_out_module_0 ex_design_control_master cr0_reset msg_clk_reset msg_clk_reset clk_reset Connect the debug clock domain reset to the components listed in Table 17Debug Clock Domain Reset Co. Table 17. Debug Clock Domain Reset Connections Clock Source Component Port dbg_clk.clk_reset nios2dpx_0 debug_rst_n

36 Page 36 Specifying Component Connections Specifying PE Message Switch Connections Connect the Processing Element Message Switch connections as listed in Table 18. Table 18. PE Message Switch Connections Source pe_msg_switch_0.out_port_0 pe_msg_switch_0.out_port_1 pe_msg_switch_0.out_port_2 pe_msg_switch_0.out_port_3 st_pipeline_stage_0.source0 nios2dpx_0.message_out Example_PE_1.message_out Example_PE_2.message_out ex_nios2dpx_out_module_0.msg_out ex_nios2dpx_in_module_0.msg_out Destination nios2dpx_0.message_in Example_PE_1.message_in Example_PE_2.message_in st_pipeline_stage_0.sink0 ex_nios2dpx_out_module_0.msg_in pe_msg_switch_0.in_port_0 pe_msg_switch_0.in_port_1 pe_msg_switch_0.in_port_2 pe_msg_switch_0.in_port_3 pe_msg_switch_0.in_port_4 Specifying the Datapath Processor's Context Register Interface Connections The input PE puts context-specific information in the input context registers through the input context register interface. The output PE reads context-specific information from the output context registers through the output context register interface. Connect the Nios II DPX datapath processor's input and output context register interfaces as listed in Table 19. Table 19. Nios II DPX Datapath Processor Input and Output Context Interface Connections Source ex_nios2dpx_in_module_0.avm_cri ex_nios2dpx_out_module_0.avm_cro nios2dpx_0.context_in nios2dpx_0.context_out Destination Specifying the Datapath Processor's CID Request Interface Connection The input PE requests a new CID when it receives an Ethernet frame, over the datapath processor's CID request interface. Connect the CID request interface as listed in Table 20.

37 Page 37 Table 20. Nios II DPX Datapath Processor CID Request Interface Connection Source Destination nios2dpx_0.cid_request ex_nios2dpx_in_module_0.atl_fcid Specifying the Datapath Processor's Fixed-Latency Data Master Connection The Nios II DPX datapath processor accesses data memory over the fixed-latency data master interface. Connect this interface as listed in Table 21. Table 21. Nios II DPX Datapath Processor Fixed-Latency Data Master Connection Source Destination nios2dpx_0.fixed_latency_data_master_0 data_memory.s1 Specifying the Datapath Processor's Variable-Latency Data Master Connection The Nios II DPX datapath processor accesses variable-latency peripherals such as PIO and JTAG UART over the variable-latency data master interface. Because the peripherals operate at a slower clock speed than the variable-latency data master interface (which operates on the processor clock), these peripherals are connected over a pipelined clock-crossing bridge. Make connections as listed in Table 22. Table 22. Nios II DPX Datapath Processor Variable-Latency Data Master Connections Source Destination nios2dpx_0.variable_latency_data_master_0 mm_bridge_0.m0 vldm_cdc.m1 vldm_cdc.m1 vldm_cdc.m1 mm_bridge_0.s0 vldm_cdc.s1 pio_led.s1 pio_pb_in.s1 Jtag_uart_0.avalon_jtag_slave Specifying Stimulus Generator Connections The stimulus block used in this design provides stimulus to the input PE and receives processed packets from the output PE.

38 Page 38 Make connections as listed in Table 23. Table 23. Stimulus Block Connections Source nios2_dpx_exdes_stim_0.stim_out ex_nios2dpx_out_module_0.st_data_out Destination ex_nios2dpx_in_module_0.atl_sink nios2_dpx_exdes_stim_0.stim_in Specifying System Console Control Connections System Console, running on a host computer, can access the control and status registers of the example PE and stimulus blocks over the JTAG to Avalon Master Bridge. Make connections as listed in Table 24. Table 24. System Console Control Connections Source Destination Example_PE_1.csr ex_design_control_master.master Example_PE_2.csr nios2_dpx_exdes_stim_0.csr Specifying Frame Buffer Connections The input PE stores the frame it receives in a FIFO. Both the input PE and the output PE must have access to the FIFO. Make connections as listed in Table 25 to establish the FIFO link to the input PE and output PE. Table 25. Frame Buffer Connections Source Destination ex_nios2dpx_in_module_0.atl_source sc_fifo_0.out sc_fifo_0.in ex_nios2dpx_out_module_0.fifo_buffer_sink

39 Page 39 Specifying Memory Map Addresses Specify base addresses for the component interfaces as shown in Table 26. Table 26. Memory Map Component Interface Base nios2_dpx_exdes_stim_0.csr Example_PE_1.csr Example_PE_2.csr data_memory.s1 nios2dpx_0.context_in nios2dpx_0.context_out mm_bridge_0.s0 vldm_cdc.s1 pio_led_in.s1 pio_pb_in.s1 jtag_uart_0.avalon_jtag_slave 0x x x x x x x x x x x

40 Page 40 Verifying Project Settings Click the Project Settings tab in Qsys and verify the following information: Device family: Stratix IV Clock crossing adapter type: Handshake Limit interconnect pipeline stages to: 0 Generation ID: 0 In the block diagram, also verify that the signals in Table 27 are exported. Table 27. Exported Signals Signal Type cpu_clk_clk_in cpu_clk_clk_in_reset msg_clk_clk_in msg_clk_clk_in_reset dbg_clk_clk_in dbg_clk_clk_in_reset pio_led_external_connection pio_pb_in_external_connection nios2dpx_0_reset_request_n Clock Reset Clock Reset Clock Reset Conduit Conduit Reset Save Project 1. Save the Qsys system, File->Save

41 Page 41 Adding the Nios II DPX Processor to the Top-Level System This section goes through the steps to add the Nios II DPX system, created in the previous section, to the top-level Qsys system. Figure 12 shows a preview of the top-level Qsys system, Nios2DPX_example_system_top.qsys, to be completed in this section. As with the Nios II DPX system, this Qsys system has some blocks already instantiated, indicated in gray in Figure 12. This top-level Qsys system can be used as a template for any new Nios II DPX design. Opening the Top-Level Qsys System Open Nios2DPX_example_system_top.qsys, which is partially completed to contain reset and clock management components, as shown in gray in Top-Level Qsys Sys. Adding the Nios II DPX Datapath Processor System The Nios II DPX system created in the previous section is a Qsys component that must be added to the top-level Qsys design. Under the System Contents Tab: 1. Under Project > System in the Qsys Component Library pane, double-click Nios2DPX_example_system. 2. Click Finish 3. Rename to system_0 if the instance is not so named. 4. To export the pio_pb_in_external_connection conduit endpoint, a. Click the Export column in the signal's row in Qsys. b. Rename the endpoint to pio_pb_in_external_connection. 5. To export the pio_led_external_connection conduit endpoint, a. Click the Export column in the signal's row in Qsys. b. Rename the endpoint to pio_led_external_connection. 6. Delete the clock and reset names under the Export column for system_0, this will allow them to be connected internally.

42 Page 42 Figure 12. Top-Level Qsys System Specifying Clock Connections The top-level Qsys system contains a PLL instance that has three outputs, mapped as shown in Table 28. Table 28. PLL Clocks PLL Output Clock Frequency clock_source Processor clock (cpu_clk) 400 MHz clock_source_1 Message Clock (msg_clk) 200 MHz Clock_source_2 Debug Clock (dbg_clk) 100 MHz

43 Page 43 Connect the Processor Clock PLL output to the components listed in Table 29. Table 29. PLL c0 Clock Connections Clock Source Component Port Port pll_0.clock_source system_0 (Nios II DPX processor system) ex_nios2dpx_reset_mgmnt_0 cpu_clk_clk_in cpu_clk Connect the Message Clock PLL output to the components listed in Table 30. Table 30. PLL c1 Clock Connections Clock Source Component Port Port dri_clk pll_0.clock_source_1 ex_nios2dpx_reset_mgmnt_0 system_0 (Nios II DPX processor system) dro_clk msg_clk msg_clk_clk_in Connect the debug clock PLL output to the components listed in Table 31. Table 31. PLL c2 Clock Connections Clock Source Component Port Port pll_0.clock_source_2 ex_nios2dpx_reset_mgmnt_0 system_0 (Nios II DPX processor system) dbg_clk dbg_clk_clk_in

44 Page 44 Specifying Reset Connections The example reset-management circuitry component, ex_nios2dpx_reset_mgmnt_0, implements reset-management for the different clock domains and generates synchronized reset outputs. Table 32 lists the reset output signals and their synchronization. Table 32. Reset-Management Circuitry Reset Output Signals Reset Output Clock Domain Reset Inputs cpu_clk_arstn Processor Clock glob_arstn, dpx_dbg_rst_req msg_clk_arstn Message Clock glob_arstn, dpx_dbg_rst_req dri_clk_arstn Context-In Register Clock glob_arstn, dpx_dbg_rst_req dro_clk_arstn Context-Out Register Clock glob_arstn, dpx_dbg_rst_req dbg_clk_arstn Debug Clock glob_arstn In the Nios II DPX system, the Context-In and Context-Out clocks are provided by the message clock. Therefore, in the top level, the dri_clk_arstn and dro_clk_arstn remain unconnected. Connect the processor clock domain reset signal to the components listed in Table 33. Table 33. Processor Clock Domain Reset Connections Reset Source Component Port ex_nios2dpx_reset_mgmnt_0.cpu_clk_arstn system_0 (Nios II DPX processor system) cpu_clk_clk_in_reset Connect the message clock domain reset signal to the components listed in Table 34. Table 34. Message Clock Domain Reset Connections Reset Source Component Port ex_nios2dpx_reset_mgmnt_0.msg_clk_arstn system_0 (Nios II DPX processor system) msg_clk_clk_in_reset Connect the debug clock domain reset signal to the components listed in Table 35. Table 35. Debug Clock Domain Reset Connections Reset Source Component Port ex_nios2dpx_reset_mgmnt_0.dbg_clk_arstn system_0 (Nios II DPX processor system) dbg_clk_clk_in_reset

45 Page 45 Connect the Nios II DPX datapath processor's reset request signal to the components listed in Table 36. Table 36. Nios II DPX Processor Reset Request Connection Reset Source Component Port system_0.nios2dpx_0_reset_request_n ex_nios2dpx_reset_mgmnt_0 dpx_dbg_rst_req Verifying Project Settings Click the Project Settings tab in Qsys and verify the following information: Device family: Stratix IV Clock crossing adapter type: Handshake Limit interconnect pipeline stages to: 1 Generation ID: 0 Also verify that the block diagram shows the ports listed in Table 37. Table 37. Block Diagram Ports Signal Type refclk_50m_clk_in refclk_50m_clk_in_reset pio_led_external_connection pio_pb_in_external_connection Clock Reset Conduit Conduit If warnings appear in the Qsys Messages tab, you can disregard them. Generating the HDL Design Files Now that both the Qsys systems are complete, from the Generation tab in the top-level Qsys system, Nios2DPX_example_system_top.qsys, select Create HDL design files for synthesis. Verify the paths where the output is to be generated. Click the Generate button. Compiling the Quartus II Project The Nios II DPX Simple Packet Processing design example's Quartus II project has predetermined timing constraints and is ready for compilation. When Qsys generation is complete, from the Processing menu in Quartus II, click Start Compilation. Compilation produces the nios2dpx_spp_4sgx230.sof file for configuring the FPGA.

46 Page 46 Configuring the FPGA When compilation is done, program the Stratix IV GX FPGA development board with the nios2dpx_spp_4sgx230.sof file. Note: When using the dedicated JTAG connection, there are two devices in the JTAG chain. To set up the JTAG Chain, perform an Auto Detect in the Quartus II Programmer. Select the appropriate device (ES or non-es) depending on your board. Creating Software The working directory contains a folder, software/pp_demo, which contains software source files for the Nios II DPX design. Creating the software entails the following steps: Creating the board support package (BSP) Creating the application based on the BSP. These two steps are performed in the Nios II Software Build Tools (SBT) for Eclipse. For information on creating software projects and using the Nios II SBT for Eclipse, refer to the Nios II DPX Datapath Processor Handbook. To start the Nios II SBT for Eclipse, from Qsys, on the Tools menu click Nios II Software Build Tools for Eclipse. Select an appropriate Eclipse Workspace location. Creating the BSP To create the BSP, perform the following steps. 1. In the Project Explorer view, right-click to open the context menu. 2. Point to New and click Nios II Board Support Package. The Nios II Board Support Package dialog box appears. 3. Type Nios2DPX_BSP as the Project name. 4. Click the button next to SOPC Information File name to display an Open dialog box. 5. Browse to the working directory and select the Nios2DPX_example_system_top.sopcinfo file. 6. Click Open. This step populates the CPU field with a Nios II DPX instance, and the BSP type changes to Altera Lightweight HAL. 7. Click Finish. The Project Explorer view updates to show a Nios2DPX_BSP project. 8. Right-click the Nios2DPX_BSP project in the Project Explorer view, point to Nios II, and click Generate BSP. 9. When BSP generation completes, right-click the Nios2DPX_BSP project in the Project Explorer view and click Build Project to build the BSP. Creating the Application To create the application project, perform the following steps. 1. In the Project Explorer view, right-click to open the context menu. 2. Point to New and click Nios II Application. The Nios II Application dialog box appears.

47 Page Type Nios2DPX_App as the Project Name. 4. Click the button next to BSP Location to open a Project Selection dialog box. 5. Select Nios2DPX_BSP. 6. Click OK. 7. Click Finish. The Project Explorer view updates to show a Nios2DPX_App project. 8. Copy all files (.c,.h and.tcl) from the <working directory>/software/pp_demo folder into the Nios2DPX_App folder. 9. Right-click the Nios2DPX_App project to open the context menu. 10. Click Refresh. 11. Right-click the Nios2DPX_App project to open the context menu. 12. Click Build Project. This step generates the Nios2DPX_App.elf file.

48 Page 48 Debugging the Simple Packet Processing Example Software This section shows the steps required to download and debug the simple packet processing software example in the Nios II SBT for Eclipse. For general information on debugging Nios II DPX software, refer to the Nios II DPX Datapath Processor Handbook. This section assumes that the Stratix IV GX FPGA development board is programmed with the nios2dpx_spp_4sgx230.sof file, as described in Configurin. Debugging the software entails the following steps: Starting GDB server from System Console Starting the Nios II DPX debugger from Nios II SBT for Eclipse Starting GDB Server Perform the following steps to download the software image and start the GDB server: 1. In the Project Explorer view of the Nios II SBT for Eclipse, select the Nios2DPX_App project. 2. In the Nios II menu, click System Console. 3. In the System Console dialog box, select Nios2DPX_App as the application project and click OK. This step opens System Console. 4. In System Console, in the Tools menu click GDB Server Control Panel. This step opens the GDB Server Control Panel GUI in System Console. The GDB Server Control Panel's Available Processors view lists a Nios II DPX Processor when the board is programmed correctly and connection is established with the Nios II DPX debug module. 5. In the GDB Server Control Panel view, for Select an ELF file to debug, browse to locate the Nios2DPX_app.elf file built in Creating the. 6. Click Select Elf to download the.elf file, holding the processor in reset, and close this dialog box. 7. Set the Base TCP Port for GDB Servers field to Click Launch Server. The Running Servers list box displays an entry for a Nios II DPX Processor, listing the correct.elf file and showing as the TCP port. The Messages pane reports GDB Server listening on port Starting the Nios II DPX Debugger The Nios II DPX debugger can be started after the GDB server has downloaded the.elf file and is in a listening mode, allowing connection with the Nios II DPX debugger. 1. In Nios II SBT for Eclipse, right-click the Nios2DPX_App project and select Debug As-> Nios II Hardware Running the Debugger The Debug view lists eight threads, one for each physical thread on the Nios II DPX datapath processor. The debugger halts at the first instruction of crt0.s, which is andi r0, r0, Select <path>nios2dpx_app.elf in the Debug view and click the Resume button to resume all eight threads.

49 Page 49 The eight LEDs on the board start displaying a pattern. This pattern is displayed by thread 0 on the processor, providing a visual indication that thread 0 is executing instructions in the software application. The other threads of the processor perform the packet processing. The next section shows you how to analyze this packet-processing activity using a visualization tool. See the Nios II DPX Datapath Processor Handbook for information on Nios II DPX processor-specific debug information available in the Nios II SBT for Eclipse. Using the Statistics Visualization Tool The tutorial's software folder contains a Tcl script files that were copied to the Nios2DPX_App folder in the previous step. These Tcl script files, when run from the System Console, provide visual information on the Nios II DPX processor's workings as well as the ability to control parameters in the example PEs and the stimulus generator. Overview of Tcl Scripts for Visualization The Nios II DPX Simple Packet Processing design example includes the following top-level Tcl scripts: stats.tcl This script file accesses the Nios II DPX processor's statistics block and displays statistics information visually. ex_des_procs.tcl This script file provides the ability to control parameters in the example PE and the stimulus generator. It accesses the Avalon slave ports on these components over the JTAG to Avalon Master Bridge. These scripts can serve as a starting point for a custom visualization view. Starting the Statistics Visualization GUI Perform the following steps to start the Nios II DPX processor statistics visualization GUI. 1. In the Tcl Console of the System Console, type: pwd This command lists the current working directory. Make sure the current working directory is Nios2DPX_App where the Tcl script files are located. 2. In the Tcl Console, type: source stats.tcl This command opens the Nios II DPX statistics visualization GUI.

50 Page 50 Understanding the Statistics Visualization GUI The statistics visualization GUI displays information retrieved from the Nios II DPX datapath processor's statistics collector. This section provides an overview of what is displayed. Processor Activity Graphical Representation Figure 13 shows the graphical view provided by the statistics visualization GUI for processor activity. Figure 13. Processor Activity Information The processor activity view includes the following information: The NiosDPX Metrics gauge provides a visual indication of the processor's workload across all eight threads. The bar graph in the middle shows the percentage distribution of various instruction categories executed by all the threads. The following categories are shown: mem_read Memory read instructions executed. mem_write Memory write instructions executed. arith_logic Arithmetic and logic instructions executed. comp_branch Comparison and branch instructions executed. debug Debug instructions executed. exit exit instructions executed. This instruction is executed by threads when in the idle state waiting to be scheduled to execute a task. snd_sndi snd and sndi instructions executed by threads. This instruction is executed to send messages from a task. other all other instructions that do not fall in the categories listed above. The buttons located at the right side of the display allow you to start and stop monitoring as well as reset cumulative data gathered by the statistics visualization tool. Threads Information The thread information, shown in Figure 14, provides numeric information on the instructions, executed for each thread, grouped into categories. For the tutorial example, thread 0 executes an infinite loop to blink LEDs and therefore does not execute any snd, sndi or exit instructions. The other threads participate in packet processing and therefore execute exit, snd, and sndi instructions.

51 Page 51 Figure 14. Thread Information Level Counters Information The Nios II DPX datapath processor's statistics collector maintains the following level counters, as shown in Level C: CID0 CYCLES Minimum, maximum, and last known value of processor clock ticks taken to execute all tasks for the lifetime of context ID 0. Because CIDs are reused and are not associated with a specific task, these statistics represent an average number of processor clock cycles across all tasks. Free CID FIFO Minimum, maximum, and last known CID free list size. Input Task FIFO Minimum, maximum, and last known size of the receive message FIFO. Messages in the receive message FIFO represent tasks waiting to be scheduled. CID Reorder FIFO Minimum, maximum, and last known size of the CID message reorder buffer. Figure 15 shows the graphical representation of these counters in the visualization GUI. Figure 15. Level Counters Information

52 Page 52 CID Information The Nios II DPX statistics collector counts the number of messages received for each CID. Figure 16 shows how the CID message counts are displayed. The stats.tcl script is configured to display information for 32 CIDs, because the Nios II DPX datapath processor in this example is configured to have 32 CIDs. Figure 16. CID Information Input Task ID Information The Nios II DPX statistics collector counts the number of messages received for each task ID. This received message count represents the total times a task is executed by the processor. Figure 17 shows how the task message counts are displayed. For the Nios II DPX Simple Packet Processing design example, the only task IDs defined for use on the Nios II DPX datapath processor are TID_NEW_PACKET_TASKID, TID_LOOKUP_LOCAL_IP_AND_PORT, TID_LOOKUP_LOCAL_MAC, and TID_PROCESS_FRAME_DATA (0, 16, 17, and 32). Figure 17. Input Task ID Information Output Task ID Information The Nios II DPX statistics collector counts the number of messages transmitted for each task ID. Output Task ID Informationshows how the outgoing message counts are displayed.

53 Page 53 For the Nios II DPX Simple Packet Processing design example, the only task IDs defined for PEs that receive messages from the Nios II DPX datapath processor are TID_LOOKUP_LOCAL_IP_AND_PORT, TID_LOOKUP_LOCAL_MAC, and TID_PROCESS_FRAME_DATA (16, 17 and 32). Messages with task ID TID_NULL_MESSAGE (63) shown in Figure 18 Output Task ID Informationare null messages used for freeing the CID when processing for a context is complete. Figure 18. Output Task ID Information Modifying Stimulus Parameters The ex_des_procs.tcl script allows you to set parameters on the stimulus block as well as the two example PEs. In System Console, perform the following steps to run the ex_des_procs.tcl script, which opens the Nios II DPX processor statistics visualization GUI. 3. In the Tcl Console, type: pwd This command lists the current working directory. Make sure the current working directory is Nios2DPX_App, where the Tcl script files are located. 4. In the Tcl Console, type: source ex_des_procs.tcl 5. In the Tcl console, type: ex_design::start Changing the IPG The stimulus block in the Qsys design provides packets that are separated by an IPG measured in message clock cycles. You can modify the IPG at run time. At the Tcl console, type: ex_design::stimulus_ipg 200 Observe the visualization information change. Then type: ex_design::stimulus_ipg 1000 Observe the processor visualization information change to reflect a lower load as the packet rate drops.