Refer to the individual chapter's revision history section for more details about the changes and previous revision history.

FPGAs can implement logic that functions as a complete microprocessor while providing many flexibility options.

An important difference between discrete microprocessors and FPGAs is that an FPGA contains no logic when it powers up. Before you run software on a Nios^® II based system, you must configure the FPGA with a hardware design that contains a Nios^® II processor. To configure an FPGA is to electronically program the FPGA with a specific logic design. The Nios^® II processor is a true soft-core processor: it can be placed anywhere on the FPGA, depending on the other requirements of the design. Two different variants of the processor are available for Nios^® II Gen2, each with flexible features.¹

To enable your FPGA-based embedded system to behave as a discrete microprocessor-based system, your system should include the following:

• A JTAG interface to support FPGA configuration and hardware and software debugging
• A power-up FPGA configuration mechanism

If your system has these capabilities, you can begin refining your design from a pretested hardware design loaded in the FPGA. Using an FPGA also allows you to modify your design quickly to address problems or to add new functionality. You can test these new hardware designs easily by reconfiguring the FPGA using your system's JTAG interface.

The JTAG interface supports hardware and software development. You can perform the following tasks using the JTAG interface:

• Configure the FPGA
• Download and debug software
• Communicate with the FPGA through a UART-like interface (JTAG UART)
• Debug hardware (with the Signal Tap II embedded logic analyzer)
• Program flash memory

After you configure the FPGA with your Nios^® II processor-based design, the software development flow is similar to the flow for discrete microcontroller designs.

Whether you are a hardware designer or a software designer, read the Nios^® II Hardware Development Tutorial to start learning about designing embedded systems on an Intel FPGA. The “ Nios^® II System Development Flow” section is particularly useful in helping you to decide how to approach system design using Intel's embedded hardware and software development tools. Intel recommends that you read this tutorial before starting your first design project. The tutorial teaches you the basic hardware and software flow for developing Nios^® II processor-based systems.

Designing with FPGAs gives you the flexibility to implement some functionality in discrete system components, some in software, and some in FPGA-based hardware. This flexibility makes the design process more complex. The Platform Designer system design tool helps to manage this complexity. Even if you decide a soft-core processor does not meet your application's needs, Platform Designer can still play a vital role in your system by providing mechanisms for peripheral expansion or processor offload.

The figure below illustrates the overall Nios^® II system design flow, including both hardware and software development. This illustration is greatly simplified. There are numerous correct ways to use the Intel tools to create a Nios^® II system.

This section contains a list of resources to help you find design help. Your resource options include traditional Intel-based support such as online documentation, training, and My Support, as well as web-based forums and Wikis. The best option depends on your requirements and your current stage in the design cycle.

Intel recommends that you seek support in the following order:

1. Look for relevant literature on the Intel Documentation page, especially on the Documentation: Nios^® II Processor page.
2. For reference, see the related design examples in the Intel FPGA Design Store.
3. Consult one of the following community-owned resources:
   • The Nios Forum, available on the Intel^® FPGA Community website.
   • The Intel^® FPGA Wiki website
   • Rocketboards for Linux support
   Note: Intel is not responsible for the contents of the Nios Forum and Intel^® FPGA Wiki websites, which are maintained by public authors and experts outside of Intel.
4. Contact technical support through the My Intel page of the Intel website to get support directly from Intel.
5. Contact your local Intel sales office or sales representative, or your field application engineer (FAE).

To learn how the tools work together and how to use them in an online or instructor-led environment, register for training. Several training options are available. For information about general training, refer to the Training page of the Intel FPGA website.

For detailed information about available courses and their locations, visit the Embedded SW Designer Curriculum page of the Intel FPGA website. This page contains information about both online and instructor-led training.

You can access documentation about the Nios^® II processor and embedded design from your Nios^® II EDS installation directory at < Nios^® II EDS install dir> \documents\index.htm. To access this page directly on Windows platforms, on the Start menu, click All Programs. On the All Programs menu, on the Intel submenu, on the Nios^® II EDS <version> submenu, click Nios^® II <version> Documentation. This web page contains links to the latest Nios^® II documentation.

The Documentation: Nios^® II Processor page of the Intel website includes a list and links to available documentation. At the bottom of this page, you can find links to various product pages that include Nios^® II processor online demonstrations and embedded design information.

The other chapters in the Embedded Design Handbook are a valuable source of information about embedded hardware and software design, verification, and debugging. Each chapter contains links to the relevant overview documentation.

Many third parties have participated in developing solutions for embedded designs with Intel FPGAs through the Intel DSN Program. For up-to-date information about the third-party solutions available for the Nios^® II processor, visit the Nios^® II Processor page of the Intel website, and select the Ecosystem tab; or run a search on the Intellectual Property Find IP web page..

Several community forums are also available. These forums are not controlled by Intel. The Intel FPGA Forum's Marketplace provides third-party hard and soft embedded systems-related IP. The forum also includes an unsupported projects repository of useful example designs. You are welcome to contribute to these forum pages.

For Linux support, you can also refer to Rocketboards.

Traditional support is available from the Support Center or through your local Field Application Engineer (FAE). You can obtain more informal support by visiting the Nios Forum section of the Intel FPGA Forum or by browsing the information contained on the Intel FPGA Wiki. Many experienced developers, from Intel and elsewhere, contribute regularly to Wiki content and answer questions on the Nios Forum.

The following definitions explain some of the unique terminology for describing Platform Designer and Nios II processor-based systems:

• Component—A named module in Platform Designer that contains the hardware and software necessary to access a corresponding hardware peripheral.
• Custom instruction—Custom hardware processing integrated with the Nios^® II processor's ALU. The programmable nature of the Nios^® II processor and Platform Designer-based design supports this implementation of software algorithms in custom hardware. Custom instructions accelerate common operations. (The Nios^® II processor floating-point instructions are implemented as custom instructions).
• Custom peripheral—An accelerator implemented in hardware. Unlike custom instructions, custom peripherals are not connected to the CPU's ALU. They are accessed through the system interconnect fabric. (See System interconnect fabric). Custom peripherals offload data transfer operations from the processor in data streaming applications.
• ELF (Executable and Linking Format)—The executable format used by the Nios^® II processor. This format is arguably the most common of the available executable formats. It is used in most of today's popular Linux/BSD operating systems.
• HAL (Hardware Abstraction Layer)—A lightweight runtime environment that provides a simple device driver interface for programs to communicate with the underlying hardware. It provides a POSIX-like software layer and wrapper to the newlib C library.
• Nios^® II Command Shell—The command shell you use to access Nios^® II and Platform Designer command-line utilities.
  • On Windows platforms, a Nios^® II Command Shell is a Cygwin bash with the environment properly configured to access command-line utilities.
  • On Linux platforms, to run a properly configured bash, type < Nios^® II EDS install path>/nios2_command_shell.sh
• Nios^® II Embedded Development Suite (EDS)—The complete software environment required to build and debug software applications for the Nios^® II processor.
• Nios^® II Software Build Tools (SBT)—Software that allows you to create Nios^® II software projects, with detailed control over the software build process.
• Nios^® II Software Build Tools for Eclipse—An Eclipse-based development environment for Nios^® II embedded designs, using the SBT for project creation and detailed control over the software build process. The SBT for Eclipse provides software project management, build, and debugging capabilities.
• Platform Designer —Software that provides a GUI-based system builder and related build tools for the creation of FPGA-based subsystems, with or without a processor.
• System interconnect fabric—An interface through which the Nios^® II processor communicates to on- and off-chip peripherals. This fabric provides many convenience and performance-enhancing features.

Although you develop your FPGA-based design in Platform Designer, you must perform the following tasks in other tools:

• Connect signals from your FPGA-based design to your board level design
• Connect signals from your Platform Designer system to other signals in the FPGA logic
• Constrain your design

To connect your FPGA-based design to your board-level design, perform the following two tasks:

• Identify the top level of your FPGA design.
• Assign signals in the top level of your FPGA design to pins on your FPGA using any of the methods mentioned in the Intel I/O Management, Board Development Support, and Signal Integrity Analysis Resource Center page of the Intel FPGA website.

You must define the clock and reset pins for your Platform Designer system. You must also define each I/O signal that is required for proper system operation. The figure below shows the top-level block diagram of a Platform Designer system that includes a Nios^® II processor. The large symbol in this top-level diagram, labeled std_1s40, represents the Platform Designer system. The flag-shaped pin symbols in this diagram represent off-chip (off-FPGA) connections.

Figure 3. Top-level Block Diagram

For more information about connecting your FPGA design pins, refer to the Intel I/O Management, Board Development Support, and Signal Integrity Analysis Resource Center page of the Intel website.

To ensure your design meets timing and other requirements, you must constrain the design to meet these requirements explicitly using tools provided in the Quartus^® Prime software or by a third party EDA provider. The Intel^® Quartus^® Prime software uses your constraint information during design compilation to achieve Intel’s best possible results.

Platform Designer simplifies the task of building complex hardware systems on an FPGA. Platform Designer allows you to describe the topology of your system using a graphical user interface (GUI) and then generate the hardware description language (HDL) files for that system. The Intel^® Quartus^® Prime software compiles the HDL files to create an SRAM Object File (.sof). For additional information about Platform Designer, refer to the Intel^® Quartus^® Prime Handbook.

Platform Designer allows you to choose the processor core type and the level of cache, debugging, and custom functionality for each Nios^® II processor. Your design can use on-chip resources such as memory, PLLs, DSP functions, and high-speed transceivers. You can construct the optimal processor for your design using Platform Designer.

After you construct your system using Platform Designer, and after you add any required custom logic to complete your top-level design, you must create pin assignments using the Intel^® Quartus^® Prime software. The FPGA’s external pins have flexible functionality, and a range of pins are available to connect to clocks, control signals, and I/O signals.

For information about how to create pin assignments, refer to Intel^® Quartus^® Prime Help and to the I/O Management chapter in Volume 2: Design Implementation and Optimization of the Intel^® Quartus^® Prime Handbook.

Intel recommends that you start your design from a small pretested project and build it incrementally. Start with one of the many Platform Designer example designs available from the All Design Examples web page of the Intel website, or with an example design from the Nios^® II Hardware Development Tutorial.

Platform Designer allows you to create your own custom components using the component editor. In the component editor you can import your own source files, assign signals to various interfaces, and set various component and parameter properties.

Before designing a custom component, you should become familiar with the interface and signal types that are available in Platform Designer.

You should use dynamic addressing for slave interfaces on all new components. Dynamically addressable slave ports include byte enables to qualify which byte lanes are accessed during read and write cycles. Dynamically addressable slave interfaces have the added benefit of being accessible by masters of any data width without data truncation or side effects.

To learn about the interface and signal types that you can use in Platform Designer, refer to Avalon Interface Specifications. To learn about using the component editor, refer to the Component Editor chapter in the Intel^® Quartus^® Prime Handbook.

As you add each hardware component to the system, test it with software. If you do not know how to develop software to test new hardware components, Intel recommends that you work with a software engineer to test the components.

The Nios^® II EDS includes several software examples, located in your Nios^® II EDS installation directory (nios2eds), at < Nios^® II EDS install dir>\examples\software. After you run a simple software design—such as the simplest example, Hello World Small—build individual systems based on this design to test the additional interfaces or custom options that your system requires. Intel recommends that you start with a simple system that includes a processor with a JTAG debug module, an on-chip memory component, and a JTAG UART component, and create a new system for each new untested component, rather than adding in new untested components incrementally.

After you verify that each new hardware component functions correctly in its own separate system, you can combine the new components incrementally in a single Platform Designer system. Platform Designer supports this design methodology well, by allowing you to add components and regenerate the project easily.

For detailed information about how to implement the recommended incremental design process, refer to the Verification and Board Bring-Up chapter of the Embedded Design Handbook.

To understand the Nios^® II software development process, you must understand the definition of a Platform Designer system. Platform Designer is a system development tool for creating systems including processors, peripherals, and memories. The tool enables you to define and generate a complete Platform Designer very efficiently. Platform Designer does not require that your system contain a Nios^® II processor, although it provides complete support for integrating Nios^® II processors with your system.

A Platform Designer system is similar in many ways to a conventional embedded system; however, the two kinds of system are not identical. An in-depth understanding of the differences increases your efficiency when designing your Platform Designer system.

In Intel Platform Designer solutions, the hardware design is implemented in an Intel FPGA device. An Intel FPGA device is volatile—contents are lost when the power is turned off— and reprogrammable. When an Intel FPGA is programmed, the logic cells inside it are configured and connected to create a Platform Designer system, which can contain Nios^® II processors, memories, peripherals, and other structures. The system components are connected with Avalon^® interfaces. After the FPGA is programmed to implement a Nios^® II processor, you can download, run, and debug your system software on the system.

Understanding the following basic characteristics of FPGAs and Nios^® II processors is critical for developing your Nios^® II software application efficiently:

• FPGA devices and Platform Designer—basic properties:
  • Volatility—The FPGA is functional only after it is configured, and it can be reconfigured at any time.
  • Design—Many Intel Platform Designer systems are designed using Platform Designer and the Intel^® Quartus^® Prime software, and may include multiple peripherals and processors.
  • Configuration—FPGA configuration can be performed through a programming cable, such as the Intel^® FPGA Download Cable , which is also used for Nios^® II software debugging operations.
  • Peripherals—Peripherals are created from FPGA resources and can appear anywhere in the Avalon memory space. Most of these peripherals are internally parameterizable.
• Nios^® II processor—basic properties:
  • Volatility—The Nios^® II processor is volatile and is only present after the FPGA is configured. It must be implemented in the FPGA as a system component, and, like the other system components, it does not exist in the FPGA unless it is implemented explicitly.
  • Parameterization—Many properties of the Nios^® II processor are parameterizable in Platform Designer, including core type, cache memory support, and custom instructions, among others.
  • Processor Memory—The Nios^® II processor must boot from and run code loaded in an internal or external memory device.
  • Debug support—To enable software debug support, you must configure the Nios^® II processor with a debug core. Debug communication is performed through a programming cable, such as the Intel^® FPGA Download Cable.
  • Reset vector—The reset vector address can be configured to any memory location.
  • Exception vector—The exception vector address can be configured to any memory location.

The recommended design flow requires that you maintain several small Platform Designer systems, each with its Intel^® Quartus^® Prime project and the software you use to test the new hardware. A Platform Designer design requires the following files and folders:

• Intel^® Quartus^® Prime Project File (.qpf)
• Intel^® Quartus^® Prime Settings File (.qsf)

  The .qsf file contains all of the device, pin, timing, and compilation settings for the Intel^® Quartus^® Prime project.

• One of the following types of top-level design file:
  • Block Design File (.bdf)
  • Verilog Design File (.v)
  • VHDL Design File (.vhd)

    Platform Designer generates most of the HDL files for your system, so you do not need to maintain them when preserving a project. You need only preserve the HDL files that you add to the design directly.

    For details about the design file types, refer to the Intel^® Quartus^® Prime Help.

• Platform Designer Design File (.qsys)
• Platform Designer Information File (.sopcinfo)

  This file contains an XML description of your Platform Designer system. Platform Designer and downstream tools, including the Nios^® II Software Build Tools (SBT), derive information about your system from this file.

• Your software application source files

To replicate an entire project (both hardware and software), simply copy the required files to a separate directory. You can create a script to automate the copying process. After the files are copied, you can proceed to modify the new project in the appropriate tools: the Intel^® Quartus^® Prime software, Platform Designer, the SBT for Eclipse, the SBT in the command shell, or the Nios^® II Integrated Development Environment (IDE).

For more information about all of these files, refer to the "Archiving Projects" chapter in the Intel^® Quartus^® Prime Handbook Volume 1: Design and Synthesis.

The figure below illustrates a Platform Designer system design that includes a high-performance external bus or switch to connect an industry-standard processor to an external interface of an IP core inside the FPGA. This IP core also includes an Avalon^® -MM master port that connects to the Platform Designer system interconnect fabric. As the figure illustrates, Intel provides a library of components, typically Avalon^® -MM slave devices, that connect seamlessly to the Platform Designer system interconnect fabric.

Figure 5. FPGA with a Bus or Switch Interface Bridge for Peripheral Expansion

The design below includes an external processor that interfaces to a PCI Express endpoint inside the FPGA. The system interconnect fabric inside the implements a partial crossbar switch between the endpoint that connects to the external processor and two additional PCI Express root ports that interface to an Ethernet card and a marking engine. In addition, the system includes some custom logic, a memory controller to interface to external DDR SDRAM memory, a USB interface port, and an interface to external flash memory. Platform Designer automatically generates the system interconnect fabric to connect the components in the system.

Figure 6. FPGA with a Processor Bus or SPI for Peripheral Expansion

Alternatively, you can also implement your logic in Verilog HDL or VHDL without using Platform Designer. Below the figure illustrates a modular design that uses the FPGA for co-processing with a second module to implement the interface to the processor. If you choose this option, you must write all of the HDL to connect the modules in your system.

The table below summarizes the components Intel provides to connect an Intel FPGA device to an external processor. As this table indicates, three of the components are also available for use in the Parameter Editor design flow in addition to Platform Designer. Alternative implementations of these components are also available through the Intel IP Core Partners Program (DSN) partners. The partners offer a broad portfolio of IP cores optimized for Intel devices.

For a complete list of third-party IP for Intel FPGAs, refer to the Intellectual Property: Find IP web page of the Intel website.

The table below summarizes the most popular options for peripheral expansion in Platform Designer systems that include an industry-standard processor. All of these are available in Platform Designer. Some are also available using the Parameter Editor.

For detailed information about the components available in Platform Designer refer to the Embedded Peripherals IP User Guide and the Intellectual Property: Find IP page.

The following sections discuss the high-performance interfaces that you can use to interface to an external processor.

RapidIO is a high-performance packet-switched protocol that transports data and control information between processors, memories, and peripheral devices. The RapidIO Intel^® FPGA IP function is available in Platform Designer includes Avalon^® -MM ports that translate Serial RapidIO transactions into Avalon^® -MM transactions. The Intel^® FPGA IP function also includes an optional Avalon^® Streaming ( Avalon^® -ST) interface that you can use to send transactions directly from the transport layer to the system interconnect fabric. When you select all optional features, the core includes the following ports:

• Avalon^® -MM I/O write master
• Avalon^® -MM I/O read master
• Avalon^® -MM I/O write slave
• Avalon^® -MM I/O read slave
• Avalon^® -MM maintenance master
• Avalon^® -MM system maintenance slave
• Avalon^® Streaming sink pass-through TX
• Avalon^® -ST source pass-through RX

Using the Platform Designer design flow, you can integrate a RapidIO endpoint in a Platform Designer system. You connect the ports using the Platform Designer System Contents tab and Platform Designer automatically generates the system interconnect fabric. The figure below illustrates a Platform Designer system that includes a processor and a RapidIO Intel^® FPGA IP function.

Figure 8. Example system with RapidIO Interface

Refer to the RapidIO trade association web site's product list at rapidio.org for a list of processors that support a RapidIO interface.

Refer to the following documents for a complete description of the RapidIO Intel^® FPGA IP function: RapidIO Intel^® FPGA IP Function User Guide and AN513: RapidIO Interoperability With TI 6482 DSP Reference Design.

The Intel IP Compiler for PCI Express* configured using the Platform Designer design flow uses the IP Compiler for PCI Express* 's Avalon-MM bridge module to connect the IP Compiler for PCI Express* component to the system interconnect fabric. The bridge facilitates the design of PCI Express* systems that use the Avalon-MM interface to access Platform Designer components. The figure below illustrates a design that links an external processor to an Platform Designer system using the IP Compiler for PCI Express* .

You can also implement the IP Compiler for PCI Express* using the Parameter Editor design flow. The configuration options for the two design flows are different. The IP Compiler for PCI Express* is available in Intel FPGA devices as a hard IP implementation and can be used as a root port or end point. I

Figure 9. Example System with PCI Express* Interface

The figure shows an example system in which an external processor communicates with an Intel FPGA through a PCI Express* link.

For more information about using the IP Compiler for PCI Express* refer to the following reference documents:

Intel offers a wide range of PCI local bus solutions that you can use to connect a host processor to an FPGA. You can implement the PCI Intel^® FPGA IP function using the Parameter Editor or Platform Designer design flow.

The PCI Platform Designer flow is an easy way to implement a complete Avalon-MM system which includes peripherals to expand system functionality without having to be well-acquainted with the Avalon-MM protocol. The figure below illustrates a Platform Designer system using the PCI Intel^® FPGA IP function. You can parameterize the PCI Intel^® FPGA IP function with a 32- or 64-bit interface.

Figure 10. PCI Intel^® FPGA IP Function in a Platform Designer System

For more information refer to the PCI Compiler User Guide.

The SPI Slave to Avalon^® Master Bridge component provides a simple connection between processors and Platform Designer systems through a four-wire industry standard serial interface. Host systems can initiate Avalon^® -MM transactions by sending encoded streams of bytes through the core's serial interface. The core supports read and write transactions to the Platform Designer system for memory access and peripheral expansion.

The SPI Slave to Avalon^® Master Bridge is an Platform Designer-ready component that integrates easily into any Platform Designer system. Processors that include an SPI interface can easily encapsulate Avalon^® -MM transactions for reads and writes using the protocols outlined in the SPI Slave/JTAG to Avalon^® Master Bridge Cores chapter of the Embedded Peripherals IP User Guide.

Figure 11. Example System with SPI to Avalon^® -MM Interface Component

Details of each protocol layer can be found in the following chapters of the Embedded Peripherals IP User Guide:

SPI Slave/JTAG to Avalon^® Master Bridge Cores—Provide a connection from an external host system to an Platform Designer system. Allow an SPI master to initiate Avalon^® -MM transactions.

Avalon^® -ST Bytes to Packets and Packets to Bytes Converter Cores—Provide a connection from an external host system to an Platform Designer system. Allow an SPI master to initiate Avalon^® -ST transactions.

Avalon^® Packets to Transactions Converter Core—Receives streaming data from upstream components and initiates Avalon^® -MM transactions. Returns Avalon^® -MM transaction responses to requesting components.

The SPI Slave to Avalon^® Master Bridge Design Example demonstrates SPI transactions between an Avalon^® -MM host system and a remote SPI system.

Many bus protocols can be mapped to the system interconnect fabric either directly or with some custom bridge interface logic to compensate for differences between the interface standards. The Avalon^® -MM interface standard, which Platform Designer supports, is a synchronous, memory-mapped interface that is easy to create custom bridges for.

If required, you can use the component editor available in Platform Designer to quickly define a custom bridge component to adapt the external processor bus to the Avalon^® -MM interface or any other standard interface that is defined in the Avalon^® Interfaces Specifications. The Templates menu available in the component editor includes menu items to add any of the standard Avalon^® interfaces to your custom bridge. You can then use the Interfaces tab of the component editor to modify timing parameters including: Setup, Read Wait, Write Wait, and Hold timing parameters, if required.

For more information about the component editor, refer to the Creating Platform Designer Components chapter of the Intel^® Quartus^® Prime Handbook Volume 1: Design and Synthesis.

The Avalon^® -MM protocol requires that all masters provide byte addresses. Consequently, it may be necessary for your custom bridge component to add address wires when translating from the external processor bus interface to the Avalon^® -MM interface. For example, if your processor bus has a 16-bit word address, you must add one additional low-order address bit. If processor bus drives 32-bit word addresses, you must add two additional, low-order address bits. In both cases, the extra bits should be tied to 0. The external processor accesses individual byte lanes using the byte enable signals.

Consider the following points when designing a custom bridge to interface between an external processor and the Avalon^® -MM interface:

• The processor bus signals must comply or be adapted with logic to comply with the signals used for transactions, as described in the Avalon^® Interfaces Specifications.
• The external processor must support the Avalon^® waitrequest signal that inserts wait-state cycles for slave components
• The system bus must have a bus reference clock to drive Platform Designer interface logic in the FPGA.
• No time-out mechanism is available if you are using the Avalon^® -MM interface.
• You must analyze the timing requirements of the system. You should perform a timing analysis to guarantee that all synchronous timing requirements for the external processor and Avalon^® -MM interface are met. Examine the following timing characteristics:
  • Data t_SU, t_H , and t_CO times to the bus reference clock
  • f_MAX of the system matches the performance of the bus reference clock
  • Turn-around time for a read-to-write transfer or a write-to-read transfer for the processor is well understood

If your processor has dedicated read and write buses, you can map them to the Avalon^® -MM readdata and writedata signals. If your processor uses a bidirectional data bus, the bridge component can implement the tristate logic controlled by the processor’s output enable signal to merge the readdata and writedata signals into a bidirectional data bus at the pins of the FPGA. Most of the other processor signals can pass through the bridge component if they adhere to the Avalon^® -MM protocol. The figure below illustrates the use of a bridge component with a 32-bit external processor.

Figure 12. Custom Bridge to Adapt an External Processor to an Avalon^® -MM Slave Interface

For more information about designing with the Avalon^® -MM interface refer to the Avalon^® Interfaces Specifications.

The term endian describes data byte ordering in both hardware and software. The two most common forms of data byte ordering are little endian and big endian. Little endian means that the least significant portion of a value is presented first and stored at the lowest address in memory. Big endian means the most significant portion of a value is presented first and stored at the lowest address in memory. For example, consider the value 0x1234. In little endian format, the 4 is the first digit presented or stored. In big endian format, the 1 is the first digit presented or stored.

Endianness typically refers only to byte ordering. Bit ordering within each byte is a separate subject covered in “PowerPC Bus Byte Ordering” and “ARM BE-32 Bus Byte Ordering”.

Hardware developers can map the data bits of an interface in any order. There must be coordination and agreement among developers so that the data bits of an interface correctly map to address offsets for any master or slave interface connected to the interconnect. Consistent hardware endianness or bus byte ordering is especially important in systems that contain IP interfaces of varying data widths because the interconnect performs the data width conversion between the master and slave interfaces. The key to simplifying bus byte ordering is to be consistent system-wide when connecting IP cores to the interconnect. For example, if all but one IP core in your system use little endian bus byte ordering, modify the interface of the one big endian IP core to conform to the rest of the system.

The way an IP core presents data to the interconnect is not dependent on the internal representation of the data within the core. IP cores can map the data interface to match the bus data byte ordering specification independent of the internal arithmetic byte ordering.

Software endianness or arithmetic byte ordering is the internal representation of data within an IP core, software compiler, and peripheral drivers. Processors can treat byte offset 0 of a variable as the most or least significant byte of a multibyte word. For example, the value 0x0A0B0C0D, which spans multiple bytes, can be represented different ways. A little endian processor considers the byte 0x0D of the value to be located at the lowest byte offset in memory, whereas a big endian processor considers the byte 0x0A of the value to be located at the lowest byte offset in memory.

The example below shows a C code fragment that illustrates the difference between the little endian and big endian arithmetic byte ordering used by most processors.

In the example, the processor writes the 32-bit value 0x0A0B0C0D to memory, then reads the first byte of the value back. A little endian processor such as the Nios II processor, which considers memory byte offset 0 to be the least significant byte of a word, stores byte 0x0D to byte offset 0 of pointer location long_ptr. A processor such as a PowerPC^®, which considers memory byte offset 0 to be the most significant byte of a word, stores byte 0x0A to byte offset 0 of pointer location long_ptr. As a result, the variable byte_value is loaded with 0x0D if this code executes on a little endian Nios^® II processor and 0x0A if this code executes on a big endian PowerPC processor.

Arithmetic byte ordering is not dependent on the bus byte ordering used by the processor data master that accesses memory. However, word and halfword accesses sometimes require byte swapping in software to correctly interpret the data internally by the processor.

For more information, refer to “Arithmetic Byte Reordering” and “System-Wide Arithmetic Byte Reordering in Software”.

To ensure correct data communication, the Avalon^® -MM interface specification requires that each master or slave port of all components in your system pass data in descending bit order with data bits 7 down to 0 representing byte offset 0. This bus byte ordering is a little endian ordering. Any IP core that you add to your system must comply with the Avalon^® -MM interface specification. This ordering ensures that when any master accesses a particular byte of any slave port, the same physical byte lanes are accessed using a consistent bit ordering. For more information, refer to the Avalon^® Interface Specifications.

The interconnect handles dynamic bus sizing for narrow to wide and wide to narrow transfers when the master and slave port widths connected together do not match. When a wide master accesses a narrow slave, the interconnect serializes the data by presenting the lower bytes to the slave first. When a narrow master accesses a wide slave, the interconnect performs byte lane realignment to ensure that the master accesses the appropriate byte lanes of the slave.

For more information, refer to the Platform Designer Interconnect chapter of the Intel^® Quartus^® Prime Handbook Volume 1: Design and Synthesis

A direct memory access (DMA) engine moves memory contents from a source location to a destination location. Because Platform Designer supports dynamic bus sizing, the data widths of the source and destination memory in the examples do not need to match the width of the DMA engine. The DMA engine reads data from a source base address and sequentially increases the address until the last read completes. The DMA engine also writes data to a destination base address and sequentially increases the address until the last write completes.

The following three figures illustrate example DMA transfers to and from memory of differing data widths. The source memory is populated with an increasing sequential pattern starting with the value 0 at base address 0. The DMA engine begins transferring data starting from the base address of the source memory to the base address of the destination memory. The interconnect always transfers the lower bytes first when any width adaptation takes place. The width adaptation occurs automatically within the interconnect.

In the Nios^® II processor, the internal arithmetic byte ordering and the bus byte ordering are both little endian. Internally, the processor and its compiler map the least significant byte of a value to the lowest byte offset in memory.

For example, the figure below shows storing the 32-bit value 0x0A0B0C0D to the variable Y. The action maps the least significant byte 0x0D to offset 0 of the memory used to store the variable.

Figure 16.  Nios^® II 32-Bit Byte Mapping

The Nios^® II processor is a 32-bit processor. For data larger than 32 bits, the same mapping of the least significant byte to lowest offset occurs. For example, if the value 0x0807060504030201 is stored to a 64-bit variable, the least significant byte 0x01 of the variable is stored to byte offset 0 of the variable in memory. The most significant byte 0x08 of the variable is stored to byte offset 7 of the variable in memory. The processor writes the least significant four bytes 0x04030201 of the variable to memory first, followed by the most significant four bytes 0x08070605.

The master interfaces of the Nios^® II processor comply with Avalon^® -MM bus byte ordering by providing read and write data to the interconnect in descending bit order with bits 7 down to 0 representing byte offset 0. Because the Nios^® II processor uses a 32-bit data path, the processor can access the interconnect with seven different aligned accesses. The table below shows the seven valid write accesses that the Nios^® II processor can present to the interconnect.

The code fragment shown in the example generates all seven of the accesses described in the table in the order presented in the table, where BASE is a location in memory aligned to a four-byte boundary.

Because the way the Nios^® II processor presents data to the interconnect is Avalon-MM compliant, no extra effort is required to connect the processor to the interconnect. This section describes how to modify non-Avalon-MM compliant processor masters to achieve Avalon-MM compliance.

Some processors use a different arithmetic byte ordering than the Nios^® II processor uses, and as a result, typically use a different bus byte ordering than the Avalon-MM interface specification supports. When connecting one of these processors directly to the interconnect in a system containing other masters such as a Nios^® II processor, accesses to the same address result in accessing different physical byte lanes of the slave port. Mixing masters and slaves that conform to different bus byte ordering becomes nearly impossible to manage at a system level. These mixed bus byte ordering systems are difficult to maintain and debug. Intel requires that the master interfaces of any processors you add to your system are Avalon-MM compliant.

Processors that use a big endian arithmetic byte ordering, which is opposite to what the Nios^® II processor implements, map the most significant byte of the variable to the lowest byte offset of the variable in memory. For example, the figure below shows how a PowerPC processor core stores the 32-bit value 0x0A0B0C0D to the memory containing the variable Y. The PowerPC stores the most significant byte, 0x0A, to offset 0 of the memory containing the variable.

Figure 17. Power PC 32-Bit Byte Mapping

This arithmetic byte ordering is the opposite of the ordering shown in “ Nios^® II Processor Data Accesses”. Because the arithmetic byte ordering internal to the processor is independent of data bus byte ordering external to the processor, you can adapt processor masters with non-Avalon-MM compliant bus byte ordering to present Avalon-MM compliant data to the interconnect.

The following sections describe the bus byte ordering for the two most common processors that are not Avalon-MM complaint:

• “PowerPC Bus Byte Ordering”
• “ARM BE-32 Bus Byte Ordering”

The byte positions of the PowerPC bus byte ordering are aligned with the byte positions of the Avalon^® -MM interface specification; however, the bits within each byte are misaligned. PowerPC processor cores use an ascending bit ordering when the masters are connected to the interconnect. For example, a 32-bit PowerPC core labels the bus data bits 0 up to 31. A PowerPC core considers bits 0 up to 7 as byte offset 0. This layout differs from the Avalon^® -MM interface specification, which defines byte offset 0 as data bits 7 down to 0. To connect a PowerPC processor to the interconnect, you must rename the bits in each byte lane as shown below.

Figure 18. PowerPC Bit-Renaming Wrapper

In the figure above, bit 0 is renamed to bit 7, bit 1 is renamed to bit 6, bit 2 is renamed to bit 5, and so on. By renaming the bits in each byte lane, byte offset 0 remains in the lower eight data bits. You must rename the bits in each byte lane separately. Renaming the bits by reversing all 32 bits creates a result that is not Avalon^® -MM compliant. For example, byte offset 0 would shift to data bits 31 down to 24, not 7 down to 0 as required.

Some ARM cores use a bus byte ordering commonly referred to as big endian 32 (BE-32). BE-32 processor cores use a descending bit ordering when the masters are connected to the interconnect. For example, an ARM BE-32 processor core labels the data bits 31 down to 0. Such a processor core considers bits 31 down to 24 as byte offset 0. This layout differs from the Avalon^® -MM specification, which defines byte 0 as data bits 7 down to 0.

A BE-32 processor core accesses memory using the bus mapping shown below.

The write access behavior of the BE-32 processor shown in the table above differs greatly from the Nios^® II processor behavior shown in Table 3. The only consistent access is the full 32-bit write access. In all the other cases, each processor accesses different byte lanes of the interconnect.

To connect a processor with BE-32 bus byte ordering to the interconnect, rename each byte lane as the figure below shows.

Figure 19. ARM BE-32 Byte-Renaming Wrapper

Newer ARM processor cores offer a mode called big endian 8 (BE-8). BE-8 processor master interfaces are Avalon^® -MM compliant. Internally, the BE-8 core uses a big endian arithmetic byte ordering; however, at the bus level, the core maps the data to the interconnect with the little endian orientation the Avalon^® -MM interface specification requires.

There are numerous other ways to order the data leaving or entering a processor master interface. For those cases, the approach to achieving Avalon-MM compliance is the same. In general, apply the following three steps to any processor core to ensure Avalon-MM compliance:

1. Identify the bit order.
2. Identify the location of byte offset 0 of the master.
3. Create a wrapper around the processor core that renames the data signals so that byte 0 is located on data 7 down to 0, byte 1 is located on data 15 down to 8, and so on.

Altering your system to conform to Avalon^® -MM byte ordering modifies the internal arithmetic byte ordering of multibyte values as seen by the software. For example, an Avalon^® -MM compliant big endian processor core such as an ARM BE-8 processor accesses memory using the bus mapping shown below.

The big endian ARM BE-8 mapping in the table above matches the little endian Nios^® II processor mapping for all single byte accesses. If you ensure that your processor is Avalon^® -MM compliant, you can easily share individual bytes of data between big and little endian processors and peripherals.

However, making sure that the processor data master is Avalon^® -MM compliant only ensures that single byte accesses map to the same physical byte lanes of a slave port. In the case of multibyte accesses, the same byte lanes are accessed between the BE-8 and little endian processor; however, the value is not interpreted consistently. This mismatch is only important when the internal arithmetic byte ordering of the processor differs from other peripherals and processors in your system.

To correct the mismatch, you must perform arithmetic byte reordering in software for multibyte accesses. Interpretation of the data by the processor can vary based on the arithmetic byte ordering used by the processor and other processors and peripherals in the system.

For example, consider a 32-bit ARM BE-8 processor core that reads from a 16-bit little endian timer peripheral by performing a 16-bit read access. The ARM processor treats byte offset 0 as the most significant byte of any word. The timer treats byte offset 0 as the least significant byte of the 16-bit value. When the processor reads a value from the timer, the bytes of the value, as seen by software, are swapped. The figure below shows the swapping. A timer counter value of 0x0800 (2,048 clock ticks) is interpreted by the processor as 0x0008 (8 clock ticks) because the arithmetic byte ordering of the processor does not match the arithmetic byte ordering of the timer component.

For the values to be interpreted accurately, the processor must either read each byte lane individually and then combine the two byte reads into a single 16-bit value in software, or read the single 16-bit value and swap the bytes in software.

The same issue occurs when you apply a bus-level renaming wrapper to an ARM BE-32 or PowerPC core. Both processor cores treat byte offset 0 as the most significant byte of any value. As a result, you must handle any mismatch between arithmetic byte ordering of data used by the processor and peripherals in your system.

On the other hand, if the timer in the figure above were to treat the most significant byte of the 16-bit value as byte 0 (big endian ordering), the data would arrive at the processor master in the same arithmetic byte ordering used by the processor. If the processor and the component internally implement the same arithmetic byte ordering, no software swapping of bytes is necessary for multibyte accesses.

The figure below shows how the value 0x0800 of a big endian timer is read by the processor. The value is retained without the need to perform any byte swapping in software after the read completes.

In the previous sections, we discussed arithmetic and bus byte ordering from a processor perspective. The same concepts directly apply to any component in your system. Any component containing Avalon-MM slave ports must also adhere to the Avalon-MM specification, which states that the data bits be defined in descending order with byte offset 0 positioned at bits 7 down to 0. As long as the component’s slave port is Avalon-MM compliant, you can use any arithmetic byte ordering within the component.

Typically, the most convenient arithmetic byte ordering to use throughout a system is the ordering the processor uses, if one is present. If the processor uses a different arithmetic byte ordering than the rest of the system, you must write software that rearranges the ordering for all multibyte accesses.

The majority of the IP provided by Intel that contains an Avalon-MM master or slave port uses little endian arithmetic byte ordering. If your system consists primarily of components provided by Intel, it is much easier to make the remainder of your system use the same little endian arithmetic byte ordering. When the entire system uses components that use the same arithmetic byte ordering and Avalon-MM bus byte ordering, arithmetic byte reordering within the processor or any component performing data accesses is not necessary.

Intel recommends writing your driver code to handle both big and little endian arithmetic byte ordering. For example, if the peripheral is little endian, write the peripheral driver to execute on both big and little endian processors. For little endian processors, no byte swapping is necessary. For big endian processors, all multibyte accesses requires a byte swap. Driver code selection is controlled at compile time or run time depending on the application and the peripheral.

If you cannot modify your system so that all the components use the same arithmetic byte ordering, you must implement byte reordering in software for multibyte accesses. Many processors today include instructions to accelerate this operation. If your processor does not have dedicated byte-reordering instructions, the example below shows how you can implement byte reordering in software by leveraging the macros for 16-bit and 32-bit data.

Choose the appropriate instruction or macro to perform the byte reordering based on the width of the value that requires arithmetic byte reordering. Because arithmetic byte ordering only applies to individual values stored in memory or peripherals, you must reverse the bytes of the value without disturbing the data stored in neighboring memory locations. For example, if you load a 16-bit value from a peripheral that uses a different arithmetic byte ordering, you must swap two bytes in software. If you attempt to load two 16-bit values as a packed 32-bit read access, you must swap the individual 16-bit values independently. If you attempt to swap all four bytes at once, the two individual 16-bit values are swapped, which is not the original intent of the software developer.

Your system’s memory requirements depend heavily on the nature of the applications which you plan to run on the system. Memory performance and capacity requirements are small for simple, low cost systems. In contrast, memory throughput can be the most critical requirement in a complex, high performance system. The following general types of memories can be used in embedded systems.

A primary distinction in memory types is volatility. Volatile memories only hold their contents while power is applied to the memory device. As soon as power is removed, the memories lose their contents; consequently, volatile memories are unacceptable if data must be retained when the memory is switched off. Examples of volatile memories include static RAM (SRAM), synchronous static RAM (SSRAM), synchronous dynamic RAM (SDRAM), and FPGA on-chip memory.

Non-volatile memories retain their contents when power is switched off, making them good choices for storing information that must be retrieved after a system power-cycle. Processor boot-code, persistent application settings, and FPGA configuration data are typically stored in non-volatile memory. Although non-volatile memory has the advantage of retaining its data when power is removed, it is typically much slower to write to than volatile memory, and often has more complex writing and erasing procedures. Non-volatile memory is also usually only guaranteed to be erasable a given number of times, after which it may fail. Examples of non-volatile memories include all types of flash, EPROM, and EEPROM. Most modern embedded systems use some type of flash memory for non-volatile storage.

Many embedded applications require both volatile and non-volatile memories because the two memory types serve unique and exclusive purposes. The following sections discuss the use of specific types of memory in embedded systems.

On-chip memory is the simplest type of memory for use in an FPGA-based embedded system. The memory is implemented in the FPGA itself; consequently, no external connections are necessary on the circuit board. To implement on-chip memory in your design, simply select On-Chip Memory from the Component Library on the System Contents tab in Platform Designer. You can then specify the size, width, and type of on-chip memory, as well as special on-chip memory features such as dual-port access.

On-chip memory is the highest throughput, lowest latency memory possible in an FPGA-based embedded system. It typically has a latency of only one clock cycle. Memory transactions can be pipelined, making a throughput of one transaction per clock cycle typical.

Some variations of on-chip memory can be accessed in dual-port mode, with separate ports for read and write transactions. Dual-port mode effectively doubles the potential bandwidth of the memory, allowing the memory to be written over one port, while simultaneously being read over the second port.

Another advantage of on-chip memory is that it requires no additional board space or circuit-board wiring because it is implemented on the FPGA directly. Using on-chip memory can often save development time and cost.

Finally, some variations of on-chip memory can be automatically initialized with custom content during FPGA configuration. This memory is useful for holding small bits of boot code or LUT data which needs to be present at reset.

While on-chip memory is very fast, it is somewhat limited in capacity. The amount of on-chip memory available on an FPGA depends solely on the particular FPGA device being used, but capacities range from around 15 KBytes in the smallest Cyclone II device to just under 2 MBytes in the largest Stratix III device.

Because most on-chip memory is volatile, it loses its contents when power is disconnected. However, some types of on-chip memory can be initialized automatically when the FPGA is configured, essentially providing a kind of non-volatile function. For details, refer to the embedded memory chapter of the device handbook for the particular FPGA family you are using or Intel^® Quartus^® Prime Help.

The following sections describe the best uses of on-chip memory.

Because it is low latency, on-chip memory functions very well as cache memory for microprocessors. The Nios^® II processor uses on-chip memory for its instruction and data caches. The limited capacity of on-chip memory is usually not an issue for caches because they are typically relatively small.

The low latency access of on-chip memory also makes it suitable for tightly coupled memories. Tightly coupled memories are memories which are mapped in the normal address space, but have a dedicated interface to the microprocessor, and possess the high speed, low latency properties of cache memory.

For more information regarding tightly-coupled memories, refer to the Using Tightly Coupled Memory with the Nios^® II Processor Tutorial.

For some software programming functions, particularly mathematical functions, it is sometimes fastest to use a LUT to store all the possible outcomes of a function, rather than computing the function in software. On-chip memories work well for this purpose as long as the number of possible outcomes fits reasonably in the capacity of on-chip memory available.

Embedded systems often need to regulate the flow of data from one system block to another. FIFOs can buffer data between processing blocks that run most efficiently at different speeds. Depending on the size of the FIFO your application requires, on-chip memory can serve as very fast and convenient FIFO storage.

For more information regarding FIFO buffers, refer to the On-Chip FIFO Memory Core chapter of the Embedded Peripheral IP User Guide.

On-chip memory is poorly suited for applications which require large memory capacity. Because on-chip memory is relatively limited in capacity, avoid using it to store large amounts of data; however, some tasks can take better advantage of on-chip memory than others. If your application utilizes multiple small blocks of data, and not all of them fit in on-chip memory, you should carefully consider which blocks to implement in on-chip memory. If high system performance is your goal, place the data which is accessed most often in on-chip memory cache.

Depending on the type of FPGA you are using, several types of on-chip memory are available. For details on the different types of on-chip memory available to you, refer to the device handbook for the particular FPGA family you are using.

To optimize the use of the on-chip memory in your system, follow these guidelines:

• Set the on-chip memory data width to match the data-width of its primary system master. For example, if you are connecting the on-chip memory to the data master of a Nios^® II processor, you should set the data width of the on-chip memory to 32 bits, the same as the data-width of the Nios^® II data master. Otherwise, the access latency could be longer than one cycle because the system interconnect fabric performs width translation.
• If more than one master connects to an on-chip memory component, consider enabling the dual-port feature of the on-chip memory. The dual-port feature removes the need for arbitration logic when two masters access the same on-chip memory. In addition, dual-ported memory allows concurrent access from both ports, which can dramatically increase efficiency and performance when the memory is accessed by two or more masters. However, writing to both slave ports of the RAM can result in data corruption if there is not careful coordination between the masters.

To minimize FPGA logic and memory utilization, follow these guidelines:

• Choose the best type of on-chip memory for your application. Some types are larger capacity; others support wider data-widths. The embedded memory section in the device handbook for the appropriate FPGA family provides details on the features of on-chip memories.
• Choose on-chip memory sizes that are a power of 2 bytes. Implementing memories with sizes that are not powers of 2 can result in inefficient memory and logic use.

The term external SRAM refers to any static RAM (SRAM) device that you connect externally to a FPGA. There are several varieties of external SRAM devices. The choice of external SRAM and its type depends on the nature of the application. Designing with SRAM memories presents both advantages and disadvantages.

External SRAM devices provide larger storage capacities than on-chip memories, and are still quite fast, although not as fast as on-chip memories. Typical external SRAM devices have capacities ranging from around 128 KBytes to 10 MBytes. Specialty SRAM devices can even be found in smaller and larger capacities. SRAMs are typically very low latency and high throughput devices, slower than on-chip memory only because they connect to the FPGA over a shared, bidirectional bus. The SRAM interface is very simple, making connecting to an SRAM from an FPGA a simple design task. You can also share external SRAM buses with other external SRAM devices, or even with external memories of other types, such as flash or SDRAM.

The primary disadvantages of external SRAM in an FPGA-based embedded system are cost and board real estate. SRAM devices are more expensive per MByte than other high-capacity memory types such as SDRAM. They also consume more board space per MByte than both SDRAM and FPGA on-chip memory, which consumes none.

External SRAM is quite effective as a fast buffer for medium-size blocks of data. You can use external SRAM to buffer data that does not fit in on-chip memory and requires lower latency than SDRAM provides. You can also group multiple SRAM memories to increase capacity.

SRAM is also optimal for accessing random data. Many SRAM devices can access data at non-sequential addresses with the same low latency as sequential addresses, an area where SDRAM performance suffers. SRAM is the ideal memory type for a large LUT holding the data for a color conversion algorithm that is too large to fit in on-chip memory, for example.

External SRAM performs relatively well when used as execution memory for a processor with no cache. The low latency properties of external SRAM help improve processor performance if the processor has no cache to mask the higher latency of other types of memory.

Poor uses for external SRAM include systems which require large amounts of storage and systems which are cost-sensitive. If your system requires a block of memory larger than 10 MBytes, you may want to consider a different type of memory, such as SDRAM, which is less expensive.

There are several types of SRAM devices. The following types are the most popular:

• Asynchronous SRAM—This is the slowest type of SRAM because it is not dependent on a clock.
• Synchronous SRAM (SSRAM)—Synchronous SRAM operates synchronously to a clock. It is faster than asynchronous SRAM but also more expensive.
• Pseudo-SRAM—Pseudo-SRAM (PSRAM) is a type of dynamic RAM (DRAM) which has an SSRAM interface.
• ZBT SRAM—ZBT (zero bus turnaround) SRAM can switch from read to write transactions with zero turnaround cycles, making it very low latency. ZBT SRAM typically requires a special controller to take advantage of its low latency features.

To get the best performance from your external SRAM devices, follow these guidelines:

• Use SRAM interfaces which are the same data width as the data width of the primary system master that accesses the memory.
• If pin utilization or board real estate is a larger concern than the performance of your system, you can use SRAM devices with a smaller data width than the masters that accesses them to reduce the pin count of your FPGA and possibly the number of memory devices on the PCB. However, this change results in reduced performance of the SRAM interface.

Flash memory is a non-volatile memory type used frequently in embedded systems. In FPGA-based embedded systems, flash memory is always external because FPGAs do not contain flash memory. Because flash memory retains its contents after power is removed, it is commonly used to hold microprocessor boot code as well as any data which needs to be preserved in the case of a power failure. Flash memories are available with either a parallel or a serial interface. The fundamental storage technology for parallel and serial flash devices is the same.

Unlike SRAM, flash memory cannot be updated with a simple write transaction. Every write to a flash device uses a write command consisting of a fixed sequence of consecutive read and write transactions. Before flash memory can be written, it must be erased. All flash devices are divided into some number of erase blocks, or sectors, which vary in size, depending on the flash vendor and device size. Entire sections of flash must be erased as a unit; individual words cannot be erased. These requirements sometimes make flash devices difficult to use.

The primary advantage of flash memory is that is non-volatile. Modern embedded systems use flash memory extensively to store not only boot code and settings, but large blocks of data such as audio or video streams. Many embedded systems use flash memory as a low power, high reliability substitute for a hard drive.

Among other non-volatile types of memory, flash memory is the most popular for the following four reasons:

• It is durable.
• It is erasable.
• It permits a large number of erase cycles.
• It is low-cost.

You can share flash buses with other flash devices, or even with external memories of other types, such as external SRAM or SDRAM.

A major disadvantage of flash is its write speed. Because you can only write to flash devices using special commands, multiple bus transactions are required for each flash write. Furthermore, the actual write time, after the write command is sent, can be several microseconds. Depending on clock speed, the actual write time can be in the hundreds of clock cycles. Because of the sector-erase restriction, if you need to change a data word in the flash, you must complete the following steps:

1. Copy the entire contents of the sector into a temporary buffer.
2. Erase the sector.
3. Change the single data word in the temporary buffer.
4. Write the temporary buffer back to the flash memory device.

This procedure contributes to the poor write speed of flash memory devices. Because of its poor write speed, flash memory is typically used only for storing data which must be preserved after power is turned off.

Flash memory is effective for storing any data that you wish to preserve if power is removed from the system. Common uses of flash memory include storage of the following types of data:

• Microprocessor boot code
• Microprocessor application code to be copied to RAM at system startup
• Persistent system settings, including the following types of settings:
  • Network MAC address
  • Calibration data
  • User preferences
• FPGA configuration images
• Media (audio, video)

Because of flash memory's slow write speeds, you should not use it for anything that does not need to be preserved after power-off. SRAM is a much better alternative if volatile memory is an option. Systems that use flash memory usually also include some SRAM as well.

One particularly poor use of flash is direct execution of microprocessor application code. If any of the code's writable sections are located in flash memory, the software simply will not work, because flash memory cannot be written without using its special write commands. Systems that store application code in flash memory usually copy the application to SRAM before executing it.

There are several types of flash devices. The following types are the most popular:

• Serial flash – This flash has a serial interface to preserve device pins and board space. Because many serial flash devices have their own specific interface protocol, it is best to thoroughly read a serial flash device's datasheet before choosing it. Intel EPCS configuration devices are a type of serial flash.

  For more information about EPCS configuration devices, refer to the Documentation: Configuration Devices page on the Intel website.

• NAND flash – NAND flash can achieve very high capacities, up to multiple GBytes per device. The interface to NAND flash is a bit more complicated than that of CFI flash. It requires either a special controller or intelligent low-level driver software. You can use NAND Flash with Intel FPGAs; however, Intel does not provide any built-in support.

SDRAM is another type of volatile memory. It is similar to SRAM, except that it is dynamic and must be refreshed periodically to maintain its content. The dynamic memory cells in SDRAM are much smaller than the static memory cells used in SRAM. This difference in size translates into very high-capacity and low-cost memory devices.

In addition to the refresh requirement, SDRAM has other very specific interface requirements which typically necessitate the use of special controller hardware. Unlike SRAM, which has a static set of address lines, SDRAM divides up its memory space into banks, rows, and columns. Switching between banks and rows incurs some overhead, so that efficient use of SDRAM involves the careful ordering of accesses. SDRAM also multiplexes the row and column addresses over the same address lines, which reduces the pin count necessary to implement a given size of SDRAM. Higher speed varieties of SDRAM such as DDR, DDR2, and DDR3 also have strict signal integrity requirements which need to be carefully considered during the design of the PCB.

SDRAM devices are among the least expensive and largest-capacity types of RAM devices available, making them one of the most popular. Most modern embedded systems use SDRAM. A major part of an SDRAM interface is the SDRAM controller. The SDRAM controller manages all the address-multiplexing, refresh and row and bank switching tasks, allowing the rest of the system to access SDRAM without knowledge of its internal architecture.

For information about the SDRAM controllers available for use in Intel FPGAs, refer to the External Memory Interface Handbook.

SDRAM's most significant advantages are its capacity and cost. No other type of RAM combines the low cost and large capacity of SDRAM, which makes it a very popular choice. SDRAM also makes efficient use of pins. Because row and column addresses are multiplexed over the same address pins, fewer pins are required to implement a given capacity of memory. Finally, SDRAM generally consumes less power than an equivalent SRAM device.

In some cases, you can also share SDRAM buses between multiple SDRAM devices, or even with external memories of other types, such as external SRAM or flash memory.

Along with the high capacity and low cost of SDRAM, come additional complexity and latency. The complexity of the SDRAM interface requires that you always use an SDRAM controller to manage SDRAM refresh cycles, address multiplexing, and interface timing. Such a controller consumes FPGA logic elements that would normally be available for other logic.

SDRAM suffers from a significant amount of access latency. Most SDRAM controllers take measures to minimize the amount of latency, but SDRAM latency is always greater than that of regular external SRAM or FPGA on-chip memory. However, while first-access latency is high, SDRAM throughput can actually be quite high after the initial access latency is overcome, because consecutive accesses can be pipelined. Some types of SDRAM can achieve higher clock frequencies than SRAM, further improving throughput. The SDRAM interface specification also employs a burst feature to help improve overall throughput.

SDRAM is generally a good choice in the following circumstances:

• Storing large blocks of data—SDRAM's large capacity makes it the best choice for buffering large blocks of data such as network packets, video frame buffers, and audio data.
• Executing microprocessor code—SDRAM is commonly used to store instructions and data for microprocessor software, particularly when the program being executed is large. Instruction and data caches improve performance for large programs. Depending on the system topography and the SDRAM controller used, the sequential read patterns typical of cache line fills can potentially take advantage of SDRAM's pipeline and burst capabilities.

SDRAM may not be the best choice in the following situations:

• Whenever low-latency memory access is required—Although high throughput is possible using SDRAM, its first-access latency is quite high. If low latency access to a particular block of data is a requirement of your application, SDRAM is probably not a good candidate to store that block of data.
• Small blocks of data—When only a small amount of storage is needed, SDRAM may be unnecessary. An on-chip memory may be able to meet your memory requirements without adding another memory device to the PCB.
• Small, simple embedded systems—If your system uses a small FPGA in which logic resources are scarce and your application does not require the capacity that SDRAM provides, you may prefer to use a small external SRAM or on-chip memory rather than devoting FPGA logic elements to an SDRAM controller.

There are a several types of SDRAM devices. The following types are the most common:

• SDR SDRAM—Single data rate (SDR) SDRAM is the original type of SDRAM. It is referred to as SDRAM or as SDR SDRAM to distinguish it from newer, double data rate (DDR) types. The name single data rate refers to the fact that a maximum of one word of data can be transferred per clock cycle. SDR SDRAM is still in wide use, although newer types of DDR SDRAM are becoming more common.
• DDR SDRAM—Double data rate (DDR) SDRAM is a newer type of SDRAM that supports higher data throughput by transferring a data word on both the rising and falling edge of the clock. DDR SDRAM uses 2.5 V SSTL signaling. The use of DDR SDRAM requires a custom memory controller.
• DDR2 SDRAM—DDR2 SDRAM is a newer variation of standard DDR SDRAM memory which builds on the success of DDR by implementing slightly improved interface requirements such as lower power 1.8 V SSTL signaling and on-chip signal termination.
• DDR3 SDRAM—DDR3 is another variant of DDR SDRAM which improves the potential bandwidth of the memory further by improving signal integrity and increasing clock frequencies.
• QDR, QDR II, and QDR II+ SRAM—Quad Data Rate (QDR) SRAM has independent read and write ports that run concurrently at double data rate. QDR SRAM is true dual-port (although the address bus is still shared), which gives this memory a high bandwidth, allowing back-to-back transactions without the contention issues that can occur when using a single bidirectional data bus. Write and read operations share address ports.
• RLDRAM II and RLDRAM 3—Reduced latency DRAM (RLDRAM) provides DRAM-based point-to-point memory devices designed for communications, imaging, server systems, networking, and cache applications requiring high density, high memory bandwidth, and low latency. The fast random access speeds in RLDRAM devices make them a viable alternative to SRAM devices at a lower cost.
• LPDDR2—LPDDR2-S is a high-speed SDRAM device internally configured as a 4- or 8-bank memory. All LPDDR2 devices use double data rate architecture on the address and command bus to reduce the number of input pins in the system. The 10-bit address and command bus contains command, address, and bank/row buffer information. Each command uses one clock cycle, during which command information is transferred on both the positive and negative edges of the clock.
• LPDDR3—LPDDR3-SDRAM is a high-speed synchronous DRAM device internally configured as an 8-bank memory. All LPDDR3 devices use double data rate architecture on the address and command bus to reduce the number of input pins in the system. The 10-bit address and command bus contains command, address, and bank buffer information. Each command uses one clock cycle, during which command information is transferred on both the positive and negative edges of the clock.

For more information about SDRAM types refer to the External Memory Interface Handbook Volume 2: Design Guidelines.

The table below lists the SDRAM controllers that Intel provides. These SDRAM controllers are available without licenses.

For more information about the available SDRAM controllers, refer to the External Memory Interface Handbook Volume 3: Reference Material.

When using the high performance DDR or DDR2 SDRAM controller, it is important to determine whether full-rate or half-rate clock mode is optimal for your application.

Half-rate mode is optimal in cases where you require the highest possible SDRAM clock frequency, or when the complexity of your system logic means that you are not able to achieve the clock frequency you need for the DDR SDRAM. In half-rate mode, the internal Avalon^® interface to the SDRAM controller runs at half the external SDRAM frequency.

In half-rate mode, the local data width (the data width inside the Platform Designer system) of the SDRAM controller is four times the data width of the physical DDR SDRAM device. For example, if your SDRAM device is 8 bits wide, the internal Avalon^® data port of the SDRAM controller is 32 bits. This design choice facilitates bursts of four accesses to the SDRAM device.

In full-rate mode, the internal Avalon interface to the SDRAM controller runs at the full external DDR SDRAM clock frequency. Use full-rate mode if your system logic is simple enough that it can easily achieve DDR SDRAM clock frequencies, or when running the system logic at half the clock rate of the SDRAM interface is too slow for your requirements.

When using full-rate mode, the local data width of the SDRAM controller is twice the data width of the physical DDR SDRAM. For example, if your SDRAM device is 16 bits wide, the internal Avalon data port of the SDRAM controller in full-rate mode is 32 bits wide. Again, this choice facilitate bursts to the SDRAM device.

SDRAM performance benefits from sequential accesses. When access is sequential, data is written or read from consecutive addresses and it may be possible to increase throughput by using bursting. In addition, the SDRAM controller can optimize the accesses to reduce row and bank switching. Each row or bank change incurs a delay, so that reducing switching increases throughput.

SDRAM devices employ bursting to improve throughput. Bursts group a number of transactions to sequential addresses, allowing data to be transferred back-to-back without incurring the overhead of requests for individual transactions. If you are using the high performance DDR/DDR2 SDRAM controller, you may be able to take advantage of bursting in the system interconnect fabric as well. Bursting is only useful if both the master and slave involved in the transaction are burst-enabled. Refer to the documentation for the master in question to check whether bursting is supported.

Selecting the burst size for the high performance DDR/DDR2 SDRAM controller depends on the mode in which you use the controller. In half-rate mode, the Avalon-MM data port is four times the width of the actual SDRAM device; consequently, four transactions are initiated to the SDRAM device for each single transfer in the system interconnect fabric. A burst size of four is used for those four transactions to SDRAM. This is the maximum size burst supported by the high performance DDR/DDR2 SDRAM controller. Consequently, using bursts for the high performance DDR/DDR2 SDRAM controller in half-rate mode does not increase performance because the system interconnect fabric is already using its maximum supported burst-size to carry out each single transaction.

However, in full-rate mode, you can use a burst size of two with the high performance DDR/DDR2 SDRAM controller. In full-rate mode, each Avalon transaction results in two SDRAM device transactions, so two Avalon transactions can be combined in a burst before the maximum supported SDRAM controller burst size of four is reached.

Many SDRAM devices, particularly DDR, DDR2, and DDR3 devices have minimum clock frequency requirements. The minimum clock rate depends on the particular SDRAM device. Refer to the datasheet of the SDRAM device you are using to find the device's minimum clock frequency.

SDRAM devices, both SDR and DDR, come in several speed grades. When using SDRAM with FPGAs, the operating frequency of the FPGA system is usually lower than the maximum capability of the SDRAM device. Therefore, it is typically not worth the extra cost to use fast speed-grade SDRAM devices. Before committing to a specific SDRAM device, consider both the expected SDRAM frequency of your system, and the maximum and minimum operating frequency of the particular SDRAM device.

This section describes the optimization of memory partitioning in a video processing application to illustrate the concepts discussed earlier.

This video processing application employs an algorithm that operates on a full frame of video data, line by line. Other details of the algorithm do not impact design of the memory subsystem. The data flow includes the following steps:

1. A dedicated DMA engine copies the input data from the video source to a buffer.
2. A Nios^® II processor operates on that buffer, performing the video processing algorithm and writing the result to another buffer.
3. A second dedicated DMA engine copies the output from the processor result buffer to the video output device.
4. The two DMAs provide an element of concurrency by copying input data to the next input buffer, and copying output data from the previous output buffer at the same time the processor is processing the current buffer, a technique commonly called ping-ponging.

As a starting point, the application uses SDRAM for all of its storage and buffering, a commonly used memory architecture. The input DMA copies data from the video source to an input buffer in SDRAM. The Nios^® II processor reads from the SDRAM input buffer, processes the data, and writes the result to an output buffer, also located in SDRAM. In addition, the processor uses SDRAM for both its instruction and data memory, as shown below.

Functionally, there is nothing wrong with this implementation. It is a frequently used, traditional type of embedded system architecture. It is also relatively inexpensive, because it uses only one external memory device; however, it is somewhat inefficient, particularly regarding its use of SDRAM. As the figure above illustrates, six different channels of data are accessed in the SDRAM.

• Processor instruction channel
• Processor data channel
• Input data from DMA
• Input data to processor
• Output data from processor
• Output data to DMA

With these many channels moving in and out of SDRAM simultaneously, especially at the high data rates required by video applications, the SDRAM bandwidth is easily the most significant performance bottleneck in the design.

This design can be optimized to operate more efficiently. These optimizations are described in the following sections.

The first optimization to improve efficiency is to move the input buffering from the SDRAM to an external SRAM device. This technique creates performance gains for the following three reasons:

• The input side of the application achieves higher throughput because it now uses its own dedicated external SRAM to bring in video data.
• Two of the high-bandwidth channels from the SDRAM are eliminated, allowing the remaining SDRAM channels to achieve higher throughput.
• Eliminating two channels reduces the number of accesses to the SDRAM memory, leading to fewer SDRAM row changes, leading to higher throughput.

The redesigned system processes data faster, at the expense of more complexity and higher cost. The figure below illustrates the redesigned system.

If the video frames are small enough to fit in FPGA on-chip memory, you can use on-chip memory for the input buffers, saving the expense and complexity of adding an external SRAM device.

Note that four channels remain connected to SDRAM:

1. Processor instruction channel
2. Processor data channel
3. Output data from processor
4. Output data to DMA

While we could probably achieve some additional performance benefit by adding a second external SRAM for the output channel, the benefit is not likely to be significant enough to outweigh the added cost and complexity. The reason is that only two of the four remaining channels require significant bandwidth from the SDRAM, the two video output channels. Assuming our Nios^® II processor contains both instruction and data caches, the SDRAM bandwidth required by the processor is likely to be relatively small. Therefore, sharing the SDRAM for processor instructions, processor data, and the video output channel is probably acceptable. If necessary, increasing the processor cache sizes can further reduce the processor's reliance on SDRAM bandwidth.

The final optimization is to add small on-chip memory buffers for input and output video lines. Because the processing algorithm operates on the video input one line at a time, buffering entire lines of input data in an on-chip memory improves performance. This buffering enables the Nios^® II processor to read all its input data from on-chip RAM—the fastest, lowest latency type of memory available.

The DMA fills these buffers ahead of the Nios^® II processor in a ping-pong scheme, in a manner analogous to the input frame buffers used for the external SRAM. The same on-chip memory line buffering scheme is used for processor output. The Nios^® II processor writes its output data to an on-chip memory line buffer, which is copied to the output frame buffer by a DMA after both the input and output ping-pong buffers flip, and the processor begins processing the next line. The figure below illustrates this memory architecture.

This section describes Intel command-line tools useful for Nios development board bringup and debugging.

This command returns information about the devices connected to your host PC through the JTAG interface, for your use in debugging or programming. Use this command to determine if you configured your FPGA correctly.

Many of the other commands depend on successful JTAG connection. If you are unable to use other commands, check whether your JTAG chain differs from the simple, single-device chain used as an example in this section.

Type jtagconfig --help from a Nios^® II command shell to display a list of options and a brief usage statement.

To use the jtagconfig command, perform the following steps:

1. Open a Nios^® II command shell.
2. In the command shell, type the following command:

   jtagconfig -n

The information in the response varies, depending on the particular FPGA, its configuration, and the JTAG connection cable type. The table below describes the information that appears in the response in the example.

The device name is read from the text file pgm_parts.txt in your Quartus^® Prime installation. In the example above, the name is EP1S40/_HARDCOPY_FPGA_PROTOTYPE because the silicon identification number on the JTAG chain for the FPGA device is 020050DD, which maps to the names EP1S40<device-specific name>, a couple of which end in the string _HARDCOPY_FPGA_PROTOTYPE. The internal nodes are nodes on the system-level debug (SLD) hub. All JTAG communication to an Intel FPGA passes through this hub, including advanced debugging capabilities such as the Signal Tap II embedded logic analyzer and the debugging capabilities in the Nios^® II EDS.

The example above illustrates a single cable connected to a single-device JTAG chain. However, your computer can have multiple JTAG cables, connected to different systems. Each of these systems can have multiple devices in its JTAG chain. Each device can have multiple JTAG debug modules, JTAG UART modules, and other kinds of JTAG nodes. Use the jtagconfig -n command to help you understand the devices with JTAG connections to your host PC and how you can access them.

This command downloads the specified .sof and configures the FPGA according to its contents. At a Nios^® II command shell prompt, type nios2-configure-sof --help for a list of available command-line options.

You must specify the cable and device when you have more than one JTAG cable ( Intel^® FPGA Download Cable ) connected to your computer or when you have more than one device (FPGA) in your JTAG chain. Use the --cable and --device options for this purpose.

To use the nios2-configure-sof command, perform the following steps:

1. Open a Nios^® II command shell.
2. In the command shell, change to the directory in which your .sof is located. By default, the correct location is the top-level Intel^® Quartus^® Prime project directory.
3. In the command shell, type the following command:

   nios2-configure-sof

The Nios^® II EDS searches the current directory for a .sof and programs it through the specified JTAG cable.

The system-console command starts a Tcl-based command shell that supports low-level JTAG chain verification and full system-level validation.This tool is available in the Nios^® II EDS starting in version 8.0.

This application is very helpful for low-level system debug, especially when bringing up a system. It provides a Tcl-based scripting environment and many features for testing your system.

The following important command-line options are available for the system-console command:

• The --script=<your script>.tcl option directs the System Console to run your Tcl script.
• The --cli option directs the System Console to open in your existing shell, rather than opening a new window.
• The --debug option directs the System Console to redirect additional debug output to stderr.
• The --project-dir=<project dir> option directs the System Console to the location of your hardware project. Ensure that you’re working with the project you intend—the JTAG chain details and other information depend on the specific project.
• The --jdi=<JDI file> option specifies the name-to-node mapping for the JTAG chain elements in your project.

For System Console usage examples and a comprehensive list of system console commands, refer to Analyzing and Debugging Designs with the System Console in volume 3 of the Intel^® Quartus^® Prime Handbook, on-line training is available.

This section describes the command-line tools for programming your Nios^® II-based design in flash memory.

When you use the Nios^® II EDS to program flash memory, the Nios^® II EDS generates a shell script that contains the flash conversion commands and the programming commands. You can use this script as the basis for developing your own command-line flash programming flow.

For more details about the Nios^® II EDS and command-line usage of the Nios^® II Flash Programmer and related tools, refer to the Nios^® II Flash Programmer User Guide.

This command programs common flash interface (CFI) memory. Because the Nios^® II flash programmer uses the JTAG interface, the nios2-flash-programmer command has the same options for this interface as do other commands. You can obtain information about the command-line options for this command with the --help option.

You can perform the following steps to program a CFI device:

1. Follow the steps in nios2-download, or use the Nios^® II EDS, to program your FPGA with a design that interfaces successfully to your CFI device.
2. Type the following command to verify that your flash device is detected correctly:

   nios2-flash-programmer –debug –base=<base address>

   where <base address> is the base address of your flash device. The base address of each component is displayed in Platform Designer. If the flash device is detected, the flash memory’s CFI table contents are displayed.

3. Convert your file to flash format (.flash) using one of the utilities elf2flash, bin2flash, or sof2flash described in elf2flash, bin2flash, and sof2flash.
4. Type the following command to program the resulting .flash file in the CFI device:

   nios2-flash-programmer –base=<base address> <file>.flashr

5. Optionally, type the following command to reset and start the processor at its reset address:

   nios2-download –g –r

These three commands are often used with the nios2-flash-programmer command. The resulting .flash file is a standard .srec file.

The following two important command-line options are available for the elf2flash command:

• The -boot=<boot copier file>.srec option directs the elf2flash command to prepend a bootloader S-record file to the converted ELF file.
• The -after=<flash file>.flash option places the generated .flash file—the converted ELF file—immediately following the specified .flash file in flash memory.

The -after option is commonly used to place the .elf file immediately following the .sof in an erasable, programmable, configurable serial EPCS or EPCQ flash device.

Before it writes to any flash device, the Nios^® II flash programmer erases the entire sector to which it expects to write. In EPCS and EPCQ devices, however, if you generate the software image using the elf2flash -after option, the Nios^® II flash programmer places the software image directly following the hardware image, not on the next flash sector boundary. Therefore, in this case, the Nios^® II flash programmer does not erase the current sector before placing the software image. However, it does erase the current sector before placing the hardware image.

When you use the flash programmer through the Nios^® II SBT, you automatically create a script that contains some of these commands. Running the flash programmer creates a shell script (.sh) in the Debug or Release target directory of your project. This script contains the detailed command steps you used to program your flash memory.

To program an arbitrary binary file to flash memory, perform the following steps:

1. Type the following command to generate your .flash file:

   bin2flash --location=<offset from the base address> \ 
   	-input=<your file> --output=<your file>.flash

2. Type the following command to program your newly created file to flash memory:

   nios2-flash-programmer -base=<base address> <your file>.flash

This section describes Intel command-line tools that are useful for software development and debugging.

This command establishes contact with stdin, stdout, and stderr in a Nios II processor subsystem. stdin, stdout, and stderr are routed through a UART (standard UART or JTAG UART) module within this system.

The nios2-terminal command allows you to monitor stdout, stderr, or both, and to provide input to a Nios^® II processor subsystem through stdin. This command behaves the same as the nios2-configure-sof command described in nios2-configure-sof with respect to JTAG cables and devices. However, because multiple JTAG UART modules may exist in your system, the nios2-terminal command requires explicit direction to apply to the correct JTAG UART module instance. Specify the instance using the -instance command-line option. The first instance in your design is 0 (-instance "0"). Additional instances are numbered incrementally, starting at 1 (-instance "1").

This command parses Nios^® II .elf files, downloads them to a functioning Nios^® II processor, and optionally runs the .elf file.

As for other commands, you can obtain command-line option information with the --help option. The nios2-download command has the same options as the nios2-terminal command for dealing with multiple JTAG cables and Nios^® II processor subsystems.

To download (and run) a Nios^® II .elf program:

1. Open a Nios^® II command shell.
2. Change to the directory in which your .elf file is located. If you use the Nios^® II SBT for development, the correct location is often the Debug or Release subdirectory of your top-level project. If you use the Nios^® II SBT, the correct location is the app folder.
3. In the command shell, type the following command to download and start your program:

   nios2-download -g <project name>.elf

4. Optionally, use the nios2-terminal command to connect to view any output or provide any input to the running program.

This command returns a brief report on the amount of memory still available for stack and heap from your project's .elf file.

This command does not help you to determine the amount of stack or heap space your code consumes during runtime, but it does tell you how much space your code has to work in.

To use the nios2-stackreport command, perform the following steps:

1. Open a Nios^® II command shell.
2. Change to the directory in which your .elf file is located.
3. In the command shell, type the following command:

   nios2-stackreport <your project>.elf

The Nios^® II EDS uses this command to validate that the files you use for the Read Only Zip Filing System are uncompressed. You can use it for the same purpose.

To use the validate_zip command, perform the following steps:

1. Open a Nios^® II command shell.
2. Change to the directory in which your .zip file is located.
3. In the command shell, type the following command:

   validate_zip <file>.zip

   If no response appears, your .zip file is not compressed.

This command starts a GNU Debugger (GDB) JTAG conduit that listens on a specified TCP port for a connection from a GDB client, such as a nios2-elf-gdb client.

pkill -9 -f nios2-gdb-server

The Nios^® II SBT for Eclipse and most of the other available debuggers use the nios2-gdb-server and nios2-elf-gdb commands for debugging. You should never have to use these tools at this low level. However, in case you prefer to do so, this section includes instructions to start a GDB debugger session using these commands, and an example GDB debugging session.

You can perform the following steps to start a GDB debugger session:

1. Open a Nios^® II command shell.
2. In the command shell, type the following command to start the GDB server on the machine that is connected through a JTAG interface to the Nios^® II system you wish to debug:

   nios2-gdb-server --tcpport 2342 --tcppersist

   If the transfer control protocol port 2342 is already in use, use a different port.

   Following is the system response:

   Using cable "
                  Intel® FPGA Download Cable [USB-0]", device 1, instance 0x00
   Pausing target processor: OK
   Listening on port 2342 for connection from GDB:

   Now you can connect to your server (locally or remotely) and start debugging.

3. Type the following command to start a GDB client that targets your .elf file:

   nios2-elf-gdb <file>.elf

The Nios^® II software build tools are command-line utilities available from a Nios^® II command shell that enable you to create application, board support package (BSP), and library software for a particular Nios^® II hardware system. Use these tools to create a portable, self-contained makefile-based project that can be easily modified later to suit your build flow.

Unlike the Nios^® II SBT-based flow, proficient use of these tools requires some expertise with the GNU make-based software build flow. Before you use these tools, refer to the Nios^® II Software Build Tools and the Nios^® II Software Build Tools Reference chapters of the Nios^® II Software Developer's Handbook.

The following sections summarize the commands available for generating a BSP for your hardware design and for generating your application software. Many additional options are available in the Nios^® II software build tools. For an overview of the tools summarized in this section, refer to the Nios^® II Software Build Tools chapter of the Nios^® II Software Developer's Handbook.

Use the following command-line tools to create a BSP for your hardware design:

• nios2-bsp-create-settings creates a BSP settings file.
• nios2-bsp-update-settings updates a BSP settings file.
• nios2-bsp-query-settings queries an existing BSP settings file.
• nios2-bsp-generate-files generates all the files related to a given BSP settings file.
• nios2-bsp is a script that includes most of the functionality of the preceding commands.
• create-this-bsp is a high-level script that creates a BSP for a specific hardware design example.

Use the following commands to create and manipulate Nios^® II application and library projects:

• nios2-app-generate-makefile creates a makefile for your application.
• nios2-lib-generate-makefile creates a makefile for your application library.
• create-this-app is a high-level script that creates an application for a specific hardware design example.

Rebuilding software after minor source code edits does not require a GUI. You can rebuild the project from a Nios^® II Command Shell, using your application's makefile. To build or rebuild your software, perform the following steps:

1. Open a Nios^® II Command Shell by executing one of the following steps, depending on your environment:
   • In the Windows operating system, on the Start menu, point to Programs > Intel FPGA > Nios^® II EDS, and click Nios^® II Command Shell.
   • In the Linux operating system, in a command shell, type the following sequence of commands:

     cd <
                    Nios® II EDS install path>
     ./nios2_command_shell.sh

2. Change to the directory in which your makefile is located. If you use the Nios^® II SBT for development, the correct location is often the Debug or Release subdirectory of your software project directory.
3. In the Command Shell, type one of the following commands:

   make

   or

   make -s

The example below illustrates the output of the make command run on a sample system.

The Nios^® II GCC toolchain contains the GNU Compiler Collection, the GNU binutils, and the newlib C library. You can follow links to detailed documentation from the Nios^® II EDS documentation launchpad found in your Nios^® II EDS distribution. To start the launchpad on Windows platforms, on the Start menu, click All Programs. On the All Programs menu, on the Nios^® II EDS <version> submenu, click Literature. On Linux platforms, open < Nios^® II EDS install dir>/documents/index.htm in a web browser. In addition, more information about the GNU GCC toolchain is available on the online.

This command returns a source code line number for a specific memory address. The command is similar to but more specific than the nios2-elf-objdump command described in nios2-elf-objdump and the nios2-elf-nm command described in nios2-elf-nm.

nios2-elf-addr2line

To use the nios2-elf-addr2line command, perform the following steps:

1. Open a Nios^® II command shell.
2. In the command shell, type the following command:

   nios2-elf-addr2line <your project>.elf <your_address_0>,\ 
   <your_address_1>,...,<your_address_n>

   If your project file contains source code at this address, its line number appears.

This command is a GDB client that provides a simple shell interface, with built-in commands and scripting capability. A typical use of this command is illustrated in the section nios2-gdb-server.

Use this command to parse information from your project's .elf file. The command is useful when used with grep, sed, or awk to extract specific information from your .elf file.

To display information about all instances of a specific function name in your .elf file, perform the following steps:

1. Open a Nios^® II command shell.
2. In the command shell, type the following command:

   nios2-elf-readelf -symbols <project>.elf | grep <function name>

This command generates an archive (.a) file containing a library of object (.o) files. The Nios^® II SBT uses this command to archive the System Library project.

To archive your object files using the nios2-elf-ar command, perform the following steps:

1. Open a Nios^® II command shell.
2. Change to the directory in which your object files are located.
3. In the command shell, type the following command:

   nios2-elf-ar q <archive_name>.a <object files>

The example shows how to create an archive of all of the object files in your current directory. In the example, the q option directs the command to append each object file it finds to the end of the archive. After the archive file is created, it can be distributed for others to use, and included as an argument in linker commands, in place of a long object file list.

Use the nios2-elf-g++ command to link your object files and archives into the final executable format, ELF.

To link your object files and archives into a .elf file, open a Nios^® II command shell and call nios2-elf-g++ with appropriate arguments. The following example command line calls the linker:

nios2-elf-g++ -T'<linker script>' -msys-crt0='<crt0.o file>' \
-msys-lib=<system library> -L '<The path where your libraries reside>' \
-DALT_DEBUG -O0 -g -Wall -mhw-mul -mhw-mulx -mno-hw-div \
-o <your project>.elf <object files> -lm

The exact linker command line to link your executable may differ. When you build a project in the Nios^® II SBT, you can see the command line used to link your application. To turn on this option in the Nios^® II SBT, on the Window menu, click Preferences, select the Nios^® II tab, and enable Show command lines when running make. You can also force the command lines to display by running make without the -s option from a Nios II command shell.

This command displays the total size of your program and its basic code sections.

To display the size information for your program, perform the following steps:

1. Open a Nios^® II command shell.
2. Change to the directory in which your .elf file is located.
3. In the command shell, type the following command:

   nios2-elf-size <project>.elf

This command displays all the strings in a .elf file.

This command strips all symbols from object files. All object files are supported, including ELF files, object files (.o) and archive files (.a).

nios2-elf-strip <options> <project> .elf

The nios2-elf-strip command decreases the size of the .elf file.

This command is useful only if the Nios^® II processor is running an operating system that supports ELF natively.If ELF is the native executable format, the entire .elf file is stored in memory, and the size savings matter.If not, the file is parsed and the instructions and data stored directly in memory, without the symbols in any case.

Linux is one operating system that supports ELF natively; uClinux is another. uClinux uses the flat (FLT) executable format, which is translated directly from the ELF.

This command starts a GDB session in which a terminal displays source code next to the typical GDB console.

The syntax for the nios2-elf-gdbtui command is identical to that for the nios2-elf-gdb command described in nios2-elf-gdb.

Two additional GDB user interfaces are available for use with the Nios^® II GDB Debugger. CGDB, a cursor-based GDB UI, is available at sourceforge.net. The Data Display Debugger (DDD) is highly recommended.

This command allows you to profile your Nios^® II system.

For details about this command and the Nios^® II EDS-based results GUI, refer to AN 391: Profiling Nios^® II Systems.

These commands run the GNU C and C++ compiler, respectively, for the Nios^® II processor.

The following simple example shows a command line that runs the GNU C or C++ compiler:

nios2-elf-gcc(g++) <options> -o <object files> <C files>

The example below is a Nios^® II EDS-generated command line that compiles C code in multiple files in many directories.

This command demangles C++ mangled names. C++ allows multiple functions to have the same name if their parameter lists differ; to keep track of each unique function, the compiler mangles, or decorates, function names. Each compiler mangles functions in a particular way.

For a full explanation, including more details about how the different compilers mangle C++ function names, refer to standard reference sources for the C++ language compilers.

To display the original, demangled function name that corresponds to a particular symbol name, you can type the following command:

nios2-elf-c++filt -n <symbol name>

For example,

nios2-elf-c++filt -n _Z11my_functionv

nios2-elf-strings <file>.elf | grep ^_Z | nios2-elf-c++filt -n

In this example, the nios2-elf-strings operation outputs all strings in the .elf file. This output is piped to a grep operation that identifies all strings beginning with _Z. (GCC always prepends mangled function names with _Z). The output of the grep command is piped to a nios2-elf-c++filt command. The result is a list of all demangled functions in a GCC C++ .elf file.

This command list the symbols in a .elf file.

The following two simple examples illustrate the use of the nios2-elf-nm command:

• nios2-elf-nm <project>.elf
• nios2-elf-nm <project>.elf | sort -n

To generate a list of symbols from your .elf file in ascending address order, use the following command:

nios2-elf-nm <project>.elf | sort -n > <project>.elf.nm

The <project> .elf.nm file contains all of the symbols in your executable file, listed in ascending address order. In this example, the nios2-elf-nm command creates the symbol list. In this text list, each symbol’s address is the first field in a new line. The -n option for the sort command specifies that the symbols be sorted by address in numerical order instead of the default alphabetical order.

Use this command to copy from one binary object format to another, optionally changing the binary data in the process.

Though typical usage converts from or to ELF files, the objcopy command is not restricted to conversions from or to ELF files. You can use this command to convert from, and to, any of the formats listed in the table below.

You can obtain information about the TekHex, ihex, and other text-based binary representation file formats online. As of the initial publication of this handbook, you can refer to the sbprojects.com knowledge-base entry on file formats.

To create an SREC file from an ELF file, use the following command:

nios2-elf-objcopy –O srec <project>.elf <project>.srec

ELF is the assumed binary format if none is listed. For information about how to specify a different binary format, in a Nios^® II command shell, type the following command:

nios2-elf-objcopy --help

Use this command to display information about the object file, usually an ELF file.

The nios2-elf-objdump command supports all of the binary formats that the nios2- elf-objcopy command supports, but ELF is the only format that produces useful output for all command-line options.

The Nios^® II EDS uses the following command line to generate object dump files:

nios2-elf-objdump -D -S -x <project>.elf > <project>.elf.objdump

Calling nios2-elf-ranlib is equivalent to calling nios2-elf-ar with the -s option (nios2-elf-ar -s).

For further information about this command, refer to nios2-elf-ar or type nios2-elf-ar --help in a Nios^® II command shell.

The Nios^® II EDS includes a complete set of C/C++ software development tools for the Nios^® II processor. In addition, a set of third-party embedded software tools is provided with the Nios^® II EDS. This set includes the MicroC/OS-II real-time operating system and the NicheStack TCP/IP networking stack. This section focuses on the use of the Intel-created tools for Nios^® II software generation. It also includes some discussion of third-party tools.

The Nios^® II EDS is a collection of software generation, management, and deployment tools for the Nios^® II processor. The toolchain includes tools that perform low-level tasks and tools that perform higher-level tasks using the lower-level tools. For more information on Linux, refer to rocketboards.org.

This section contains brief descriptions of the software design tools provided by the Nios^® II EDS, including the Nios^® II SBT development flow.

The Nios^® II EDS provides the following tools for software development:

• GNU toolchain: GCC-based compiler with the GNU binary utilities
  Note: For an overview of these and other Intel-provided utilities, refer to the " Nios^® II Command-Line Tools" chapter of this handbook.
• Nios^® II processor-specific port of the newlib C library
• Hardware abstraction layer (HAL)

  The HAL provides a simple device driver interface for programs to communicate with the underlying hardware. It provides many useful features such as a POSIX-like application program interface (API) and a virtual-device file system.

  For more information about the Intel HAL, refer to The Hardware Abstraction Layer section of the Nios^® II Gen2 Software Developer’s Handbook.

• Nios^® II SBT

  The Nios^® II SBT development flow is a scriptable development flow. It includes the following user interfaces:

  • The Nios^® II SBT for Eclipse—a GUI that supports creating, modifying, building, running, and debugging Nios^® II programs. It is based on the Eclipse open development platform and Eclipse C/C++ development toolkit (CDT) plug-ins.
  • The Nios^® II SBT command-line interface—From this interface, you can execute SBT command utilities, and use scripts (or other tools) to combine the command utilities in many useful ways.

    For more information about the Nios^® II SBT flow, refer to the Developing Nios^® II Software chapter of this handbook.

Intel recommends that you view and begin your design with one of the available software examples that are installed with the Nios^® II EDS. From simple “Hello, World” programs to networking and RTOS-based software, these examples provide good reference points and starting points for your own software development projects. The Hello World Small example program illustrates how to reduce your code size without losing all of the conveniences of the HAL.

The Nios^® II SBT flow uses the Software Build Tools to provide a flexible, portable, and scriptable software build environment. Intel recommends that you use this flow. The SBT includes a command-line environment and fits easily in your preferred software or system development environment.

The SBT flow requires that you have a .sopcinfo file for your system. The flow includes the following steps to create software for your system:

1. Create a board support package (BSP) for your system. The BSP is a layer of software that interacts with your development system. It is a makefile-based project.
2. Create your application software:
   1. Write your code.
   2. Generate a makefile-based project that contains your code.
3. Iterate through one or both of these steps until your design is complete.

For more information, refer to the software example designs that are shipped with every release of the Nios^® II EDS. For more information about these examples, refer to one of the following sections:

• “Getting Started” in the Getting Started with the Graphical User Interface chapter of the Nios^® II Gen2 Software Developer’s Handbook.
• “ Nios^® II Example Design Scripts” in the Nios^® II Software Build Tools Reference chapter of the Nios^® II Gen2 Software Developer’s Handbook.

This section provides an overview of the Nios^® II software development process and introduces terminology. The rest of the chapter elaborates the description in this section.

The Nios^® II software generation process includes the following stages and main hardware configuration tools:

1. Hardware configuration
   • Platform Designer
   • Intel^® Quartus^® Prime software
2. Software project management
   • BSP configuration
   • Application project configuration
   • Editing and building the software project
   • Running, debugging, and communicating with the target
   • Ensuring hardware and software coherency
   • Project management
3. Software project development
   • Developing with the Hardware Abstraction Layer (HAL)
   • Programming the Nios^® II processor to access memory
   • Writing exception handlers
   • Optimizing the application for performance and size
   • Real-time operating system (RTOS) support
4. Application deployment
   • Linking (run-time memory)
   • Boot loading the system application
   • Programming flash memory

In this list of stages and tools, the subtopics under the topics Software project management, Software project development, and Application deployment correspond closely to sections in the chapter.

You create the hardware for the system using the Intel^® Quartus^® Prime and Platform Designer software. The main output produced by generating the hardware for the system is the SRAM Object File (.sof), which is the hardware image of the system, and the Platform Designer Information File (.sopcinfo), which describes the hardware components and connections.

The software generation tools use the .sopcinfo file to create a BSP project. The BSP project is a collection of C source, header and initialization files, and a makefile for building a custom library for the hardware in the system. This custom library is the BSP library file (.a). The BSP library file is linked with your application project to create an executable binary file for your system, called an application image. The combination of the BSP project and your application project is called the software project.

The application project is your application C source and header files and a makefile that you can generate by running Intel-provided tools. You can edit these files and compile and link them with the BSP library file using the makefile. Your application sources can reference all resources provided by the BSP library file. The BSP library file contains services provided by the HAL, which your application sources can reference. After you build your application image, you can download it to the target system, and communicate with it through a terminal application.

You can access the makefile in the Eclipse Project Explorer view after you have created your project in the Nios^® II Software Build Tools for Eclipse framework.

The software project is flexible: you can regenerate it if the system hardware changes, or modify it to add or remove functionality, or tune it for your particular system. You can also modify the BSP library file to include additional Intel-supplied software packages, such as the read-only zip file system or TCP/IP networking stack (the NicheStack TCP/IP Stack). Both the BSP library file and the application project can be configured to build with different parameters, such as compiler optimizations and linker settings.

If you change the hardware system, you must recreate, update or regenerate the BSP project to keep the library header files up-to-date.

For information about how to keep your BSP up-to-date with your hardware, refer to “Revising Your BSP” in the Nios^® II Software Build Tools chapter of the Nios^® II Gen2 Software Developer's Handbook.