A BSP contains the following elements:

• Hardware abstraction layer
• Optional custom newlib C standard library¹
• Device drivers
• Optional software packages
• Optional real-time operating system

The Nios II EDS includes documented software examples to demonstrate all prominent features of the Nios II processor and the development environment. The examples can help you start the development of your custom design. They provide a stable starting point for exploring design options. Also, they demonstrate many commonly used features of the Nios II EDS.

The Nios II software examples directory contains the following files:

• Source file (.c)
• Header file (.h)
• readme.txt
• template.xml

• The Nios II Gen2 Processor Reference Guide defines the processor hardware architecture and features, including the instruction set architecture.
• The Embedded Peripherals IP User Guide provides a reference for the peripherals distributed with the Nios II processor. This handbook describes the hardware structure and Nios II software drivers for each peripheral.
• The Embedded Design Handbook describes how to use the software development tools effectively, and recommends design styles and practices for developing, debugging, and optimizing embedded systems.
• The Intel FPGA Knowledge Database is an Internet resource that offers solutions to frequently asked questions with an easy-to-use search engine.
• Application notes and tutorials offer step-by-step instructions on using the Nios II processor for a specific application or purpose. These documents are available on the Intel FPGA Nios II Processor Documentation web page.
• The Nios II EDS documentation launchpad. The launchpad is an HTML page installed with the Nios II EDS, which provides links to Nios II documentation, examples, and other resources. The way you open the launchpad depends on your software platform.
  • In the Windows operating system, on the Start menu, point to Programs > Intel FPGA > Nios II EDS, and click Nios II <version> Documentation.
  • In the Linux operating system, open <Nios II EDS install path>/documents/index.html in a web browser.

You specify a BSP in the second page of the wizard.

Select a descriptive name for your project. The SBT creates a folder with this name to contain the application project files.

Letters, numbers, and the underscore (_) symbol are the only valid project name characters. Project names cannot contain spaces or special characters. The first character in the project name must be a letter or underscore. The maximum filename length is 250 characters.

You select the project template from the Templates list.

The hello_world template provides an easy way to create your first Nios II project and verify that it builds and runs correctly.

To place your application project in a different folder, turn off Use default location, and specify the path in the Project location box.

On the second page, you specify the BSP to link with your application. You can create a new BSP for your application, or select an existing BSP. Creating a new BSP is often the simplest way to get a project running the first time.

You optionally specify the name and location of the BSP.

The SBT copies required source files to your project directories, and creates makefiles and other generated files. Finally, the SBT executes a make clean command on your BSP.

This section describes how to run a Nios II program using the Nios II SBT for Eclipse on Nios II hardware, such as an Intel FPGA development board.

To run a software project, right-click the application project name, point to Run As, and click Nios II Hardware. To run a software project as a ModelSim simulation, right-click the application project name, point to Run As, and click Nios II ModelSim.

This command carries out the following actions:

• Creates a Nios II run configuration.
• Builds the project executable. If all target files are up to date, nothing is built.
• Establishes communications with the target, and verifies that the FPGA is configured with the correct hardware design.
• Downloads the Executable and Linking Format File (.elf) to the target memory
• Starts execution at the .elf entry point.

Program output appears in the Nios II Console view. The Nios II Console view maintains a terminal I/O connection with a communication device connected to the Nios II processor in the hardware system, such as a JTAG UART. When the Nios II program writes to stdout or stderr, the Nios II Console view displays the text. The Nios II Console view can also accept character input from the host keyboard, which is sent to the processor and read as stdin.

To disconnect the terminal from the target, click the Terminate icon in the Nios II Console view. Terminating only disconnects the host from the target. The target processor continues executing the program.

This section describes how to debug a Nios II program using the Nios II SBT for Eclipse on Nios II hardware, such as an Intel FPGA development board.

To debug a software project, right-click the application project name, point to Debug As, and click Nios II Hardware. This command carries out the following actions:

• Creates a Nios II run configuration.
• Builds the project executable. If all target files are up to date, nothing is built.
• If debugging on hardware, establishes communications with the target, and verifies that the FPGA is configured with the correct hardware design.
• Downloads the .elf to the target memory.
• Sets a breakpoint at the top of main().
• Starts execution at the .elf entry point.

The Eclipse debugger with the Nios II plugins provides a Nios II perspective, allowing you to perform many common debugging tasks. Debugging a Nios II program with the Nios II plugins is generally the same as debugging any other C/C++ program with Eclipse and the CDT plugins.

For information about debugging with Eclipse and the CDT plugins, refer to the Eclipse help system.

• Controlling program execution with commands such as:
  • Suspend (pause)
  • Resume
  • Terminate
  • Step Into
  • Step Over
  • Step Return
• Setting breakpoints and watchpoints
• Viewing disassembly
• Instruction stepping mode
• Displaying and changing the values of local and global variables in the following formats:
  • Binary
  • Decimal
  • Hexadecimal
• Displaying watch expressions
• Viewing and editing registers in the following formats:
  • Binary
  • Decimal
  • Hexadecimal
• Viewing and editing memory in the following formats:
  • Hexadecimal
  • ASCII
  • Signed integer
  • Unsigned integer
• Viewing stack frames in the Debug view

When an exception is hit, the cause value in the Nios II Exception Register can be decoded using the Nios II Exceptions (In Decreasing Priority Order) table from the Nios II Gen2 Processor Reference Handbook.

You can select the operating system only at the time you create the BSP. To change operating systems, you must create a new BSP by using the Additional arguments to the nios2-bsp script.

If you intend to run the project in the Nios II ModelSim™ simulation environment, use the Additional arguments parameter to specify the location of the test bench simulation package descriptor file (.spd). The .spd file is located in the Quartus Prime project directory. Specify the path as follows: --set QUARTUS_PROJECT_DIR=<relative path> .

You can examine and modify many makefile properties in the Nios II Application Properties or Nios II Library Properties dialog box. To open the dialog box, right-click the project, click Properties > Nios II Application Properties or Properties > Nios II Library Properties.

After the SBT has created a makefile, you can modify the makefile in the following ways:

• With the Nios II SBT for Eclipse.
• With Nios II SBT commands from the Nios II Command Shell.

When modifying a makefile, the SBT preserves any previous nonconflicting modifications, regardless how those modifications were made.

After you modify a makefile with the Nios II Command Shell, in Eclipse you must right-click the project and click Update linked resource to keep the Eclipse project view in step with the makefile.

When the Nios II SBT for Eclipse modifies a makefile, it locks the makefile to prevent corruption by other processes. You cannot edit the makefile from the command line until the SBT has removed the lock.

If you want to exclude a resource (a file or a folder) from the Nios II makefile temporarily, without deleting it from the project, you can use the Remove from Nios II Build command. Right-click the resource and click Remove from Nios II Build. When a resource is excluded from the build, it does not appear in the makefile, and Eclipse ignores it. However, it is still visible in the Project Explorer, with a modified icon. To add the resource back into the build, right-click the resource and click Add to Nios II Build.

An Eclipse linked resource can be either a file or a folder. With a linked folder, all source files in the folder and its subfolders are included in the build.

When you add a linked resource (file or folder) to your project, the SBT for Eclipse adds the file or folder to your makefile with an absolute path name. You might use a linked resource to refer to common source files in a fixed location. In this situation, you can move the project to a different directory without disturbing the common source file references.

A linked resource appears with a modified icon (green dot) in the Project Explorer, to distinguish it from source files and folders that are part of the project. You can use the Eclipse debugger to step into a linked source file, exactly as if it were part of the project.

You can reconfigure your project to refer to any linked resource either as an individual file, or through its parent folder. Right-click the linked resource and click Update Linked Resource.

You can use the Remove from Nios II Build and Add to Nios II Build commands with linked resources. When a linked resource is excluded from the build, its icon is modified with a white dot.

You can use Eclipse to create a path variable, defining the location of a linked resource. A path variable makes it easy to modify the location of one or more files in your project.

For information about working with path variables and creating linked resources, refer to the Eclipse help system.

Simply turn off Enable source management to convert the makefile to user source management. When Enable source management is off, you must update your makefile manually to add or remove source files to or from the project. The SBT for Eclipse makes no changes to the list of source files, but continues to manage all other project parameters and settings in the makefile.

In a makefile with user-managed sources, you can refer to source files with an absolute path. You might use an absolute path to refer to common source files in a fixed location. In this situation, you can move the project to a different directory without disturbing the common source file references.

Projects with user-managed sources do not support the following features:

• Linked resources
• The Add to Nios II Build command
• The Remove from Nios II Build command

BSP makefiles must be managed by the SBT, either through the BSP Editor or through the SBT command-line utilities.

You can also export a Tcl script from the BSP Editor, containing all the settings in an existing BSP. By studying such a script, you can learn about how BSP Tcl scripts are constructed.

• Right-click an existing project, point to Nios II, and click BSP Editor. The editor loads the BSP Settings File (.bsp) associated with your project, and is ready to update it.
• On the Nios II menu, click Nios II BSP Editor. The editor starts without loading a .bsp file.
• Right-click an existing BSP project and click Properties. In the Properties dialog box, select Nios II BSP Properties > BSP Editor. The editor loads your .bsp file for update.

Below the console area is the Generate button. This button is enabled when the BSP settings are valid. It generates the BSP target files, as shown in the Target BSP Directory tab.

• The Main tab
• The Software Packages tab
• The Drivers tab
• The Linker Script tab
• The Enable File Generation tab
• The Target BSP Directory tab

Each tab allows you to view and edit a particular aspect of the .bsp, along with relevant command line parameters and Tcl scripts.

The settings that appear on the Main, Software Packages and Drivers tabs are the same as the settings you manipulate on the command line.

• The path to the .sopcinfo file specifying the target hardware
• The processor name
• The operating system and version

• The BSP target directory—the destination for files that the SBT copies and creates for your BSP.
• BSP settings

BSP settings appear in a tree structure. Settings are organized into Common and Advanced categories. Settings are further organized into functional groups. The available settings depend on the operating system.

When you select a group of settings, the controls for those settings appear in the pane to the right of the tree. When you select a single setting, the pane shows the setting control, the full setting name, and the setting description.

At the top of the Software Packages tab is the software package table, listing each available software package. The table allows you to select the software package version, and enable or disable the software package.

The operating system determines which software packages are available.

Many software packages define settings that you can control in your BSP. When you enable a software package, the available settings appear in a tree structure, organized into Common and Advanced settings.

When you select a group of settings, the controls for those settings appear in the pane to the right of the tree. When you select a single setting, the pane shows the setting control, the full setting name, and the setting description.

Enabling and disabling software packages and editing software package settings can have a profound impact on BSP behavior. Refer to the documentation for the specific software package for details.

At the top of the Drivers tab is the driver table, mapping components in the hardware system to drivers. The driver table shows components with driver support. Each component has a module name, module version, module class name, driver name, and driver version, determined by the contents of the hardware system. The table allows you to select the driver by name and version, as well as to enable or disable each driver.

When you select a driver version, all instances of that driver in the BSP are set to the version you select. Only one version of a given driver can be used in an individual BSP.

Many drivers define settings that you can control in your BSP. Available driver settings appear in a tree structure below the driver table, organized into Common and Advanced settings.

When you select a group of settings, the controls for those settings appear in the pane to the right of the tree. When you select a single setting, the pane shows the setting control, the full setting name, and the setting description.

Enabling and disabling device drivers, changing drivers and driver versions, and editing driver settings, can have a profound impact on BSP behavior. Refer to the relevant component documentation and driver information for details.

When you make a change to the memory configuration, the SBT validates your change.

• Add—Adds a linker section mapping to an existing linker region. The Add button opens the Add Section Mapping dialog box, where you specify a new section name and an existing linker region.
• Remove—Removes a mapping from a linker section to a linker region.
• Restore Defaults—Restores the section mappings to the default configuration set up at the time of BSP creation.

You reassign a defined linker region to a different memory device by selecting a different device name in the Memory Device Name column. The Size and Offset columns are editable. You can also edit the list of linker regions using the following buttons located next to the linker region table:

• Add—Adds a linker region in unused space on any existing device. The Add button opens the Add Memory Region dialog box, where you specify the memory device, the new memory region name, the region size, and the region's offset from the device base address.
• Remove—Removes a linker region definition. Removing a region frees the region's memory space to be used for other regions.
• Add Memory Device—Creates a linker region representing a memory device that is outside the hardware system. The button launches the Add Memory Device dialog box, where you can specify the device name, memory size and base address. After you add the device, it appears in the linker region table, the Memory Device Usage Table dialog box, and the Memory Map dialog box. This functionality is equivalent to the add_memory_device Tcl command.

• Restore Defaults—restores the memory regions to the default configuration set up at the time of BSP creation.
• Memory Usage—Opens the Memory Device Usage Table. The Memory Device Usage Table allows you to view memory device usage by defined memory region. As memory regions are added, removed, and adjusted, each device's free memory, used memory, and percentage of available memory are updated. The rightmost column is a graphical representation of the device’s usage, according to the memory regions assigned to it.
• Memory Map—Opens the Memory Map dialog box. The memory map allows you to view a map of system memory in the processor address space. The Device table is a read-only reference showing memories in the hardware system that are mastered by the selected processor. Devices are listed in memory address order.

  To the right of the Device table is a graphical representation of the processor's memory space, showing the locations of devices in the table. Gaps indicate unmapped address space.

It does not depict the actual file system, but rather the files and directories to be created or copied when the BSP is generated. Each software component, including the operating system, drivers, and software packages, specifies source code to be copied into the BSP target directory. The files are generated in the directory specified on the Main tab.

When you generate the BSP, existing BSP files are overwritten, unless you disable generation of the file in the Enable File Generation tab.

• The Information tab
• The Problems tab
• The Processing tab

• Regenerate the BSP from the command line
• Recreate the BSP as a starting point for a new BSP
• Recreate the BSP on a different hardware platform
• Examine the Tcl script to improve your understanding of Tcl command usage

The exported Tcl script captures all BSP settings that you have changed since the previous time the BSP settings file was saved. If you export a Tcl script after creating a new BSP, the script captures all nondefault settings in the BSP. If you export a Tcl script after editing a pre-existing BSP, the script captures your changes from the current editing session.

To export a Tcl script, in the Tools menu, click Export Tcl Script, and specify a filename and destination path. The file extension is .tcl.

You can later run your exported script as a part of creating a new BSP.

In this dialog box, you specify the following parameters:

• The .sopcinfo file defining the hardware platform.
• The CPU name of the targeted processor.
• The BSP type and version.

Normally, you specify the path to your .sopcinfo file relative to the BSP directory. This enables you to move, copy and archive the hardware and software files together. If you browse to the .sopcinfo file, or specify an absolute path, the Nios II BSP Editor offers to convert your path to the relative form.

This feature allows you to perform the following tasks:

• Recreate an existing BSP as a starting point for a new BSP
• Recreate a BSP on a different hardware platform
• Include custom settings common to a group of BSPs

The Tcl script can be created by hand or exported from another BSP.

If your modifications to the underlying hardware design result in BSP validation errors, the best practice is to update or recreate the BSP. Updating and recreating BSPs is very easy with the BSP Editor.

If you recreate your BSP, you might find it helpful to capture your old BSP settings by exporting them to a Tcl script. You can edit the Tcl script to remove any settings that are incompatible with the new hardware design.

• You can right-click an application, point to Run As, and click Run Configurations.
• You can right-click an application, point to Debug As, and click Debug Configurations.

Depending on which way you opened the run configuration dialog box, the title is either Run Configuration or Debug Configuration. However, both views show the same run configurations.

Each run configuration is presented on several tabs. This section describes each tab.

• Specify the processor on which to execute the program (if the hardware design provides multiple processors)
• Specify the device to use for standard I/O
• Specify the expected location, timestamp and value of the system ID
• Specify the path to the Quartus Prime JTAG Debugging Information File (.jdi)
• Enable or disable profiling

The Nios II SBT for Eclipse sets these parameters to reasonable defaults. Do not modify them unless you have a clear understanding of their effects.

• Select the cable, if more than one cable is available
• Allow software to run despite a system ID value or timestamp that differs from the hardware
• Reset the processor when the software is downloaded

The System ID Properties button allows you to examine the system ID and timestamp in both the .elf file and the hardware. This can be helpful when you need to analyze the cause of a system ID or timestamp mismatch.

• Specify the application project to run and the ELF File location
• Specify the processor and the JTAG UART connection to use
• Enable or disable system ID and timestamp checks
• Enable or disable processor controls such as download ELF, reset processor or start processor

If you have multiple run configurations, create an Eclipse launch group. Launch groups are an Eclipse feature that allows multiple run configurations to be started at the same time. You choose which run configurations are added to the group. You can use the launch group in any place where you can use a run configuration.

For details about Eclipse launch groups, refer to the Eclipse help system.

• Command-line C/C++ application project
• Command-line BSP project
• Command-line user library project

You can edit, build, debug, and manage the settings of an imported project exactly the same way you edit, build, debug, and manage the settings of a project created in Nios II SBT for Eclipse.

You can continue to develop project code in your SBT project after importing the project into Eclipse. You can edit source files and rebuild the project, using the SBT either in Eclipse or on the command line.

• Import a command-line C/C++ application
• Import a supporting project
• Debug a command-line C/C++ application
• Edit command-line C/C++ application code

When importing a project, the SBT for Eclipse might make some minor changes to your makefile. If the makefile refers to a source file located outside the project directory tree, the SBT for Eclipse treats that file as a linked resource. However, it does not add or remove any source files to or from your makefile.

When you import an application or user library project, the Nios II SBT for Eclipse allows you to choose Eclipse source management or user source management. Unless your project has an unusual directory structure, choose Eclipse source management, to allow the SBT for Eclipse to automatically maintain your list of source files.

You debug and edit an imported project exactly the same way you debug and edit a project created in Eclipse.

If you do not need BSP or user library source code visible in the debugger, you can skip this task, and proceed to debug your project exactly as if you had created it in Eclipse.

If you have several C/C++ applications based on one BSP or user library, import the BSP or user library once, and then import each application that is based on the BSP or user library. Each application's makefile contains the information needed to find and build any associated BSP or libraries.

With user source management, Eclipse never makes any changes to the list of source files in your makefile. However, the SBT for Eclipse manages all other project parameters and settings, just as with any other Nios II software project.

If your makefile refers to a source file with an absolute path, when you import with user source management, the absolute path is untouched, like any other source path. You might use an absolute path to refer to common source files in a fixed location. In this situation, you can move the project to a different directory without disturbing the common source file references.

User source management is not available with BSP projects. BSP makefiles are based on the operating system, BSP settings, selected software packages, and selected drivers. You do not specify BSP source files directly.

• Program code
• Program data
• FPGA configuration data
• File systems

Flash programmer tools allow you to program software, FPGA configuration, and application-specific binary data into flash memory devices. The tools support combining these different types of data so that they can be stored in a single flash device.

In , the Nios II SBT for Eclipse provides the Nios II flash programmer GUI-based tool and associated utilities, to help you manage and program the contents of flash memory. The sections below describe how to use these tools.

When you first open the flash programmer, no controls are available until you open or create a Flash Programmer Settings File (.flash-settings).

You specify the hardware configuration by opening a .sopcinfo file. You can locate the .sopcinfo file in either of two ways:

• Browse to a BSP settings file. The flash programmer finds the .sopcinfo file associated with the BSP.
• Browse directly to a .sopcinfo file.

Once you have identified a hardware configuration, details about the target hardware appear at the top of the Nios II flash programmer screen.

Also at the top of the Nios II flash programmer screen is the Hardware Connections button, which opens the Hardware Connections dialog box. This dialog box allows you to select a download cable, and control system ID behavior.

• The Information tab
• The Problems tab
• The Processing tab

You specify memory device information when you add the user-defined memory device to your BSP. The device information persists in the BSP settings file, allowing you to regenerate memory initialization files at any time, exactly as if the memory device were part of the hardware system.

• The physical memory width. The device’s name in the hardware system.
• The memory initialization file parameter name. Every memory device can have an HDL parameter specifying the name of the initialization file. The Nios II ModelSim launch configuration overrides the HDL parameter to specify the memory initialization filename. When available, this method is preferred for setting the memory initialization filename.
• The Mem init filename parameter can be used in Nios II systems as an alternative method of specifying the memory initialization filename. The Mem init filename parameter directly overrides any filename specified in the HDL.
• Connectivity to processor master ports. These parameters are used when creating the linker script.
• The memory type: volatile, CFI flash or EPCS flash.
• Byte lanes.
• You can also enable and disable generation of the following memory initialization file types:
  • .hex file
  • .dat and .sym files
  • .flash file

On the Advanced tab, you can control the following memory characteristics:

• The physical memory width.
• The device's name in the hardware system.
• The memory initialization file parameter name. Every memory device can have an HDL parameter specifying the name of the initialization file. The Nios II ModelSim launch configuration overrides the HDL parameter to specify the memory initialization filename. When available, this method is preferred for setting the memory initialization filename.
• The Mem init filename parameter can be used in Nios II systems as an alternative method of specifying the memory initialization filename. The Mem init filename parameter directly overrides any filename specified in the HDL.
• Connectivity to processor master ports. These parameters are used when creating the linker script.
• The memory type: volatile, CFI flash or EPCS flash.
• Byte lanes.
• You can also enable and disable generation of the following memory initialization file types:
  • .hex file
  • .dat and .sym files
  • .flash file

When you create the launch configuration, you might see the following error message:

SEVERE: The Quartus Prime project location has not been set in the ELF section. You can manually override this setting in the launch configuration's ELF file 'Advanced' properties page.

• Use __buildin_custom_* instead of -mcustom-* or #pragma to reliably generate Nios II Floating Point Custom Instructions (FPCI), independent of compiler optimization level and command line flags.
• To use -mcustom-* or #pragma for Nios II Floating Point Custom Instructions (FPCI):
  • The -ffinite-math-only flag must be used to generate fmins and fmax FPCI
  • The optimization (non -O0 flag) must be used to generate fsqrts FPCI
• Users implementing transcendental functions in hardware must use the -funsafe-math-optimizations flag to generate the FPCI for the transcendental functions fsins(), fcoss(), ftans(), fatans(), fexps(), flogs() and corresponding double-precision functions.
• The Pragma format has changed from eg. #pragma custom_fadds 253 to #pragma GCC target("custom-fadds=253") and function attributes provide an alternative format __attribute__((target("custom-fadds=253"))).
• Use the -mel/-meb flags instead of -EL/-EB for endian settings. Software Build Tool for Eclipse (SBTE) users must regenerate the BSP for this setting to take effect.
• The -mreverse-bitfields flag and reverse_bitfields pragma are no longer supported.
• The -fstack-check flag must be used instead of -mstack-check to enable stack checking.

• The -Wa,-relax-all flag in nios2-elf-gcc GCC 4.7.3 supports function calls and programs exceeding the 256 MB limit.
• When used with optimization, inline assembly code with the asm operator needs to declare values imported from C and exported back to C, using the mechanisms described on the "Exteded Asm - Assembler Instructions with C Expression Operands" page.
• Pre-standard C++ headers are not supported in GCC 4.7.3. Replace pre-standard C++ with standard C++ eg. #include <iostream.h>, cout, endl with #include <iostream>, std::cout and std::endl, respectively.
• The compile flag -Wl,--defsym foo=bar where bar is an undefined symbol, will generate error at the linker level in GCC 4.7.3. GCC 4.1.2 does not include this check.

• The name of the target .elf file (application project only)
• The library name (library project only)
• A list of symbols to be defined in the makefile
• A list of symbols to be undefined in the makefile
• A list of assembler flags
• Warning level flags
• A list of user flags
• Generation of debug symbols
• Compiler optimization level
• Generation of object dump file (application project only)
• Source file management
• Path to associated BSP (required for application, optional for library)

This behavior differs from the behavior of the Nios II SBT for Eclipse in version 9.1.

• Disable 'Nios II Console' view
• Ignore mismatched system ID
• Ignore mismatched system timestamp
• Download ELF to selected target system
• Start processor
• Reset the selected target system

The following tables describe the Eclipse CDT features not supported by the Nios II plugins. The features listed in the left column are supported by the Eclipse CDT plugins, but are not supported by Nios II plugins; and the right column lists alternative features supported by the Nios II plugins.

These command line options are:

The following shows how the application properties page looks with the new build configuration options highlighted in red:

Figure 3. Nios II Application Properties

Clicking on the Managed Configurations button shows the following dialog for adding, removing, and activating build configurations:

Figure 4. Managed Configurations

• You can invoke the command line tools from custom scripts or other tools that you might already use in your development flow.
• On a command line, you can run several Tcl scripts to control the creation of a board support package (BSP).
• You can use command line tools in a bash script to build several projects at once.

The Nios II SBT command-line interface is designed to work in the Nios II Command Shell.

• Command-line utilities
• Command-line scripts
• Tcl commands
• Tcl scripts

These elements work together in the Nios II Command Shell to create software projects.

• In the Windows operating system, on the Start menu, point to Programs > Intel FPGA > Nios II EDS <version>,and click Nios II <version> Command Shell :.
• In the Linux operating system, in a command shell, change directories to <Nios II EDS install path>, and type the command nios2_command_shell.sh.

• In the Windows operating system, execute the following command:

  “<Nios II EDS install path>/Nios II Command Shell.bat“ <command>

• In the Linux operating system, execute the following command:

  <Nios II EDS install path>/nios2_command_shell.sh <command>

For example, in Windows, to run an automated build, you might execute the following command:

“<Nios II EDS install path>/Nios II Command Shell.bat“ custom_build.sh

The Nios II Command Shell startup script (Nios II Command Shell.bat or nios2_command_shell.sh) makes no special assumptions about its initial environment. You can use the Nios II Command Shell with auto-execution from any environment that accepts commands native to your host operating system. For example, in Linux you can use crontab to schedule a job to run in the Nios II Command Shell at a later time.

To complete this tutorial, you must have the following:

• Intel FPGA Quartus Prime development software, version 8.0 or later. The software must be installed on a Windows or Linux computer that meets the Quartus Prime minimum requirements.
• The Intel FPGA Nios II Embedded Design Suite (EDS), version 8.0 or later.
• An Intel FPGA development board.
• A download cable such as the Intel FPGA USB-Blaster™ cable.

You run the Nios II SBT commands from the Nios II Command Shell.

In this section, assume that you want to build a software application for a Nios II system that features the LAN91C111 10/100 Non-PCI Ethernet Single Chip MAC + PHY component and supports the NicheStack^® TCP/IP stack. Furthermore, assume that you have organized the hardware design files and the software source files.

A simple method for creating a BSP is to use the nios2-bsp script as in the following example:

nios2-bsp ucosii . ../SOPC/ --cmd enable_sw_package altera_iniche \ 
 --set altera_iniche.iniche_default_if lan91c111 
nios2-bsp lwhal . ../user/data/FastNetProject/FastNetHW/ 
make 

The nios2-bsp script uses the .sopcinfo file to create the BSP files. You can override default settings chosen by nios2-bsp by supplying command-line arguments, Tcl scripts, or both.

You can specify multiple targets on a make command line. For example, the following command removes existing object files in the current project directory, builds the project, downloads the project to a board, and runs it:

make clean download-elf

You can modify an application or user library makefile with the nios2-lib-update-makefile and nios2-app-update-makefile utilities. With these utilities, you can execute the following tasks:

• Add source files to a project
• Remove source files from a project
• Add compiler options to a project’s make rules
• Modify or remove compiler options in a project’s make rules

The SBT creates the following types of projects:

• Nios II application—A program implementing some desired functionality, such as control or signal processing.
• Nios II BSP—A library providing access to hardware in the Nios II system, such as UARTs and other I/O devices. A BSP provides a software runtime environment customized for one processor in a hardware system. A BSP optionally also includes the operating system, and other basic system software packages such as communications protocol stacks.
• User library—A library implementing a collection of reusable functions, such as graphics algorithms.

The Nios II SBT for Eclipse provides access to a large, useful subset of SBT functionality. Any project you create in Eclipse can also be created using the SBT from the command line or in a script. Create your software project using the interface that is most convenient for you. Later, it is easy to perform additional project tasks in the other interface if you find it advantageous to do so.

The Nios II SBT creates two kinds of makefiles:

• Application or user library makefile—A simple makefile that builds the application or user library with user-provided source files
• BSP makefile—A more complex makefile, generated to conform to user-specified settings and the requirements of the target hardware system

It is not necessary to use to the generated application and user library makefiles if you prefer to write your own. However, Intel FPGA recommends that you use the SBT to manage and modify BSP makefiles.

Generated makefiles are platform-independent, calling only utilities provided with the Nios II EDS (such as nios2-elf-gcc).

The generated makefiles have a straightforward structure, and each makefile has in-depth comments explaining how it works. Intel FPGA recommends that you study these makefiles for further information about how they work. Generated BSP makefiles consist of a single main file and a small number of makefile fragments, all of which reside in the BSP directory. Each application and user library has one makefile, located in the application or user library directory.

For more information, refer to the Getting Started with the Graphical User Interface section.

• C/C++ application projects
• C/C++ user library projects
• BSP projects

This section discusses each type of project in detail.

• A device driver is associated with a specific hardware component.
• A device driver might have settings that impact its compilation. These settings become part of the BSP settings.

In the Nios II software development environment, a software package typically has the following properties:

• A software package is not associated with specific hardware.
• A software package might have settings that impact its compilation. These settings become part of the BSP settings.

Although this section describes tasks in terms of the SBT command line flow, you can also carry out most of these tasks with the Nios II SBT for Eclipse.

The mem_init.mk file includes targets designed to help you create memory initialization files (.dat, .hex, .sym, and .flash). The mem_init.mk file is designed to be included in your application makefile. Memory initialization files are used for HDL simulation, for Quartus Prime compilation of initializable FPGA on-chip memories, and for flash programming. Memories that can be initialized include M512 and M4K, but not MRAM.

Although the application makefile provides the mem_init.mk targets, it does not build any of them by default. The SBT creates the memory initialization files in the application directory (under a directory named mem_init). The SBT optionally copies them to your Quartus Prime project directory and HDL simulation directory.

QUARTUS_PROJECT_DIR = ../my_hw_design
MEM_INIT_FILE := $(BSP_ROOT_DIR)/mem_init.mk
include $(MEM_INIT_FILE)

Suppose you have a memory region named onchip_ram. The Tcl script named reserve_1024_onchip_ram.tcl separates the top 1024 bytes of onchip_ram to create a new region named onchip_special.

For more information about an explanation of each Tcl command used in this example, refer to the "Nios II Software Build Tools Reference" chapter.

# Get region information for onchip_ram memory region. 
# Returned as a list. 
set region_info [get_memory_region onchip_ram] 
# Extract fields from region information list. 
set region_name [lindex $region_info 0] 
set slave_desc [lindex $region_info 1] 
set offset [lindex $region_info 2] 
set span [lindex $region_info 3] 
# Remove the existing memory region. 
delete_memory_region $region_name 
# Compute memory ranges for replacement regions. 
set split_span 1024 
set new_span [expr $span-$split_span] 
set split_offset [expr $offset+$new_span] 
# Create two memory regions out of the original region. 
add_memory_region onchip_ram $slave_desc $offset $new_span 
add_memory_region onchip_special $slave_desc $split_offset $split_span 

If you pass this Tcl script to nios2-bsp, it runs after the default Tcl script runs and sets up a linker region named onchip_ram0. You pass the Tcl script to nios2-bsp as follows:

nios2-bsp hal my_bsp --script reserve_1024_onchip_ram.tcl

If you run nios2-bsp again to update your BSP without providing the --script option, your BSP reverts to the default linker memory regions and your onchip_special memory region disappears. To preserve it, you can either provide the --script option to your Tcl script or pass the DONT_CHANGE keyword to the default Tcl script as follows:

nios2-bsp hal my_bsp --default_memory_regions DONT_CHANGE

Intel FPGA recommends that you use the --script approach when updating your BSP. This approach allows the default Tcl script to update memory regions if memories are added, removed, renamed, or resized. Using the DONT_CHANGE keyword approach does not handle any of these cases because the default Tcl script does not update the memory regions at all.

For more information about using the --script argument, refer to the “Calling a Custom BSP Tcl Script” section.

Example 4–2. To Create a Section named .isrs in the tightly_coupled_instruction_memory on-chip memory

# Get region information for tightly_coupled_instruction_memory memory region. 
# Returned as a list. 
set region_info [get_memory_region tightly_coupled_instruction_memory] 
# Extract fields from region information list. 
set region_name [lindex $region_info 0] 
set slave [lindex $region_info 1] 
set offset [lindex $region_info 2] 
set span [lindex $region_info 3] 
# Remove the existing memory region. 
delete_memory_region $region_name 
# Compute memory ranges for replacement regions. 
set split_span 1024 
set new_span [expr $span-$split_span] 
set split_offset [expr $offset+$new_span] 
# Create two memory regions out of the original region. 
add_memory_region tightly_coupled_instruction_memory $slave $offset $new_span 
add_memory_region isrs_region $slave $split_offset $split_span 
add_section_mapping .isrs isrs_region 

The above Tcl script splits off 1 KB of RAM from the region named tightly_coupled_instruction_memory, gives it the name isrs_region, and then calls add_section_mapping to add the .isrs section to isrs_region.

Sections:
Idx Name Size VMA LMA File off Algn
.
.
.

6 .isrs 000000c0 04000c00 04000c00 000000b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
.
.
.

9 .tightly_coupled_instruction_memory 00000000 04000000 04000000 00013778 2**0
CONTENTS
.
.
.
SYMBOL TABLE:
00000000 l d .entry 00000000
30000020 l d .exceptions 00000000
30000150 l d .text 00000000
30010e14 l d .rodata 00000000
30011788 l d .rwdata 00000000
30013624 l d .bss 00000000
04000c00 l d .isrs 00000000
00000020 l d .ext_flash 00000000
03200000 l d .epcs_controller 00000000
04000000 l d .tightly_coupled_instruction_memory 00000000
04004000 l d .tightly_coupled_data_memory 00000000
.
.
.

MEMORY
{
reset : ORIGIN = 0x0, LENGTH = 32
tightly_coupled_instruction_memory : ORIGIN = 0x4000000, LENGTH = 3072
isrs_region : ORIGIN = 0x4000c00, LENGTH = 1024
.
.
.
}

If you want to know the value of one or more settings, run nios2-bsp-query-settings with the appropriate command-line options. This command sends the values of the settings you requested to stdout. Just capture the output of stdout in some variable in your script when you call nios2-bsp-query-settings. By default, the output of nios2-bsp-query-settings is an ordered list of all option values. Use the -show-names option to display the name of the setting with its value.

For more information about the nios2-bsp-query-settings command-line options, refer to the Nios II Software Build Tools Reference section.

• To prevent a default stdio device from being chosen, use the following command:

  nios2-bsp hal my_bsp --default_stdio none

• To override the default stdio device and replace it with uart1, use the following command:

  nios2-bsp hal my_bsp --default_stdio uart1

• To override the stderr device and replace it with uart2, while allowing the default Tcl script to choose the default stdout and stdin devices, use the following command:

  nios2-bsp hal my_bsp --set hal.stderr uart2

In all these cases, if you run nios2-bsp again to update your BSP, you must provide the original command-line options again to prevent the default Tcl script from choosing its own default stdio devices. Alternatively, you can call --default_stdio with the DONT_CHANGE keyword to prevent the default Tcl script from changing the stdio device settings.

You can control the optimization and debug level through the project makefile, which determines the compiler options.

Example 4–5. Default Application Makefile Settings

APP_CFLAGS_OPTIMIZATION := -O0
APP_CFLAGS_DEBUG_LEVEL := -g 

When your project is fully debugged and ready for release, you might want to enable optimization and omit the symbol table, to achieve faster, smaller executable code. To enable optimization and turn off the symbol table, edit the application makefile to contain the symbol definitions shown in the following example. The absence of a value on the right hand side of the APP_CFLAGS_DEBUG_LEVEL definition causes the compiler to omit generating a symbol table.

Example 4–6. Application Makefile Settings with Optimization

APP_CFLAGS_OPTIMIZATION := -O3 
APP_CFLAGS_DEBUG_LEVEL := 

For more information about makefile editing and make clean, refer to the “Applications and Libraries” chapter.

nios2-bsp hal my_bsp --set hal.make.bsp_cflags_debug -g \
 --set hal.make.bsp_cflags_optimization -O0r

Alternatively, you can manipulate the BSP settings with a Tcl script.

You can easily copy an existing BSP and modify it to create a different build configuration.

For more information, refer to the “Copying, Moving, or Renaming a BSP” chapter.

To change the optimization and debug level for a user library, use the same procedure as for an application.

The BSP settings file does not need to duplicate system information (such as base addresses of devices), because the nios2-bsp-generate-files utility has access to the .sopcinfo file.

The nios2-bsp-create-settings utility creates a new BSP settings file. The nios2-bsp-update-settings utility updates an existing BSP settings file. The nios2-bsp-query-settings utility reports the setting values in an existing BSP settings file. The nios2-bsp-generate-files utility generates a BSP from the BSP settings file.

HAL BSP After Build

• The .entry section maps to a nonexistent region.
• The .entry section maps to a memory region that is less than 32 bytes in length.
• The .entry section maps to a memory region that does not start on the reset vector base address.
• The .exceptions section maps to a nonexistent region.
• The .exceptions section maps to a memory region that does not start on the exception vector base address.
• The .entry section and .exceptions section map to the same device, and the memory region associated with the .exceptions section precedes the memory region associated with the .entry section.
• The .entry section and .exceptions section map to the same device, and the base address of the memory region associated with the .exceptions section is less than 32 bytes above the base address of the memory region associated with the .entry section.

nios2-bsp --script custom_bsp.tcl

nios2-bsp-create-settings --script custom_bsp.tcl

nios2-bsp-query-settings --script custom_bsp.tcl

nios2-bsp-update-settings --script custom_bsp.tcl

In the Nios II BSP editor, you can execute a Tcl script when generating a BSP, through the New BSP Settings File dialog box.

For more information about using Tcl scripts in the SBT for Eclipse, refer to Using the BSP Editor in the "Getting Started with the Graphical User Interface" chapter.

For more information, refer to an example of custom Tcl script usage in the “Creating Memory Initialization Files” chapter.

For more information about BSP defaults, refer to the “Specifying BSP Defaults” chapter.

For more information, refer to the “Using Version Control” chapter.

If a component has only one slave port connected to the Nios II processor, the slave descriptor is the same as the name of the component (for example, onchip_mem_0). If a component has multiple slave ports connecting the Nios II to multiple resources in the component, the slave descriptor is the name of the component followed by an underscore and the slave port name (for example, onchip_mem_0_s1).

# Select a device connected to the processor as the default STDIO device.
# It returns the slave descriptor of the selected device.
# It gives first preference to devices with stdio in the name.
# It gives second preference to JTAG UARTs.
# If no JTAG UARTs are found, it uses the last character device.
# If no character devices are found, it returns "none".
# Procedure that does all the work of determining the stdio device
proc choose_default_stdio {} {
   set last_stdio "none"
   set first_jtag_uart "none"
# Get all slaves attached to the processor.
   set slave_descs [get_slave_descs]
   foreach slave_desc $slave_descs {
# Lookup module class name for slave descriptor.
      set module_name [get_module_name $slave_desc]
      set module_class_name [get_module_class_name $module_name]
# If the module_name contains "stdio", we choose it
# and return immediately.
      if { [regexp .*stdio.* $module_name] } {
         return $slave_desc
}
# Assume it is a JTAG UART if the module class name contains
# the string "jtag_uart". In that case, return the first one
# found.
   if { [regexp .*jtag_uart.* $module_class_name] } {
   if {$first_jtag_uart == "none"} {
      set first_jtag_uart $slave_desc
}
}
# Track last character device in case no JTAG UARTs found.
   if { [is_char_device $slave_desc] } {
      set last_stdio $slave_desc
}
}
   if {$first_jtag_uart != "none"} {
      return $first_jtag_uart
}
   return $last_stdio
}
# Call routine to determine stdio
   set default_stdio [choose_default_stdio]
# Set stdio settings to use results of above call.
   set_setting hal.stdin $default_stdio
   set_setting hal.stdout $default_stdio
   set_setting hal.stderr $default_stdio
# Select a device connected to the processor as the default STDIO device. 
# It returns the slave descriptor of the selected device. 
# It gives first preference to devices with stdio in the name. 
# It gives second preference to JTAG UARTs. 
# If no JTAG UARTs are found, it uses the last character device. 
# If no character devices are found, it returns "none". 
# Procedure that does all the work of determining the stdio device proc choose_default_stdio {} 
{  
   set last_stdio "none"  set first_jtag_uart "none"  
# Get all slaves attached to the processor.  
   set slave_descs [get_slave_descs]  foreach slave_desc $slave_descs 
{  
# Lookup module class name for slave descriptor.  
   set module_name [get_module_name $slave_desc]  
   set module_class_name [get_module_class_name $module_name]  
# If the module_name contains "stdio", we choose it  
# and return immediately.  
   if { [regexp .*stdio.* $module_name] } 
{  
      return $slave_desc  
}  
# Assume it is a JTAG UART if the module class name contains  
# the string "jtag_uart". In that case, return the first one  
# found.  
   if { [regexp .*jtag_uart.* $module_class_name] } 
{  
      if {$first_jtag_uart == "none"
} 
{  
         set first_jtag_uart $slave_desc  
}  
}  
# Track last character device in case no JTAG UARTs found.  
   if { [is_char_device $slave_desc] } 
{  
      set last_stdio $slave_desc  
}  
}  
   if {$first_jtag_uart != "none"} 
{  
      return $first_jtag_uart  
}  
   return $last_stdio 
} 
# Call routine to determine stdio set default_stdio [choose_default_stdio] 
# Set stdio settings to use results of above call. 
   set_setting hal.stdin $default_stdio set_setting hal.stdout 
   $default_stdio set_setting hal.stderr $default_stdio 

On the command line, change to the BSP directory and type make.

• Reads the .sopcinfo file for basic system parameters such as module base addresses and clock frequencies.
• Retrieves the current system identification (ID) from the .sopcinfo file. Ensures that the correct system ID is inserted in the .elf file the next time the BSP is built.
• Adjusts the default memory map to correspond to changes in memory sizes. If you are using a custom memory map, it is untouched.
• Retains all other existing settings in the BSP settings file.

• You change your hardware design, but all BSP system-dependent settings remain consistent with the new .sopcinfo file. The following are examples of system changes that do not affect BSP system-dependent settings:
  • Changing a component’s base address
  • With the internal interrupt controller (IIC), adding or removing hardware interrupts
  • With the IIC, changing a hardware interrupt number
  • Changing a clock frequency
  • Changing a simple processor option, such as cache size or core type
  • Changing a simple component option, other than memory size.
  • Adding a bridge
  • Adding a new component
  • Removing or renaming a component, other than a memory component, the stdio device, or the system timer device
  • Changing the size of a memory component when you are using the default memory map
  Note: Unless you are sure that your modified hardware design remains consistent with your BSP settings, update your BSP. For more information, refer to the “Updating Your BSP” chapter.
• You want to eliminate any customized source files and revert to the distributed BSP code.
  Note: To revert to the distributed BSP code, you must ensure that you have not disabled generation on any BSP files.
• You have installed a new version of the Nios II EDS, and you want the updated BSP software implementations.
• When you attempt to rebuild your project, an error message indicates that the BSP must be updated.
• You have updated or recreated the BSP settings file.

For more information about generating a BSP with the SBT for Eclipse, refer to the Getting Started with the Graphical User Interface section.

For more information about the nios2-bsp-generate-files command, refer to the Nios II Software Build Tools Reference section.

• System-dependent settings are derived from the original BSP settings file, but adjusted to correspond with any changes in the hardware system.
• Non-system-dependent BSP settings persist from the original BSP settings file.

For more information about actions taken when you regenerate the BSP after updating it, refer to the “Regenerating Your BSP” chapter.

• A change to your BSP settings is required.
• Changes to your .sopcinfo file make it inconsistent with your BSP. The following are examples of system changes that affect BSP system-dependent settings:
  • Renaming the processor
  • Renaming or removing a memory, the stdio device, or the system timer device
  • Changing the size of a memory component when using a custom memory map
  • Changing the processor reset or exception slave port or offset
  • Adding or removing an external interrupt controller (EIC)
  • Changing the parameters of an EIC
• When you attempt to rebuild your project, an error message indicates that you must update the BSP.

From the command line, use the nios2-bsp-update-settings command. You can use the --script option to define the BSP with a Tcl script.

For more information about the nios2-bsp-update-settings command, refer to the "Nios II Software Build Tools Reference" chapter.

nios2-bsp-update-settings does not reapply default settings unless you explicitly call the top-level default Tcl script with the --script option.

For more information about using the default Tcl script, refer to the “Specifying BSP Defaults” chapter.

Alternatively, you can update your BSP with the nios2-bsp script. nios2-bsp determines that your BSP already exists, and uses the nios2-bsp-update-settings command to update the BSP settings file.

The nios2-bsp script executes the default Tcl script every time it runs, overwriting previous default settings.

For more information about preserving all settings, including the default settings, use the DONT_CHANGE keyword, described in the “Top Level Tcl Script for BSP Defaults” chapter.

Alternatively, you can provide nios2-bsp with command-line options or Tcl scripts to override the default settings.

For more information about using the nios2-bsp script, refer to the "Nios II Software Build Tools Reference" chapter.

• System-dependent settings are created based on the current hardware system.
• Non-system-dependent settings can be selected by the default Tcl script, by values you specify, or both.

  For more information about actions taken when you generate the BSP after recreating it, refer to the “Regenerating Your BSP” chapter.

To use Tcl scripts most effectively, it is best to create a Tcl script at the time you initially create the BSP. However, the BSP Editor enables you to export a Tcl script from an existing BSP.

For more information about exporting Tcl scripts, refer to Using the BSP Editor in the "Getting Started with the Graphical User Interface" chapter.

By recreating the BSP settings file with a Tcl script that specifies all BSP settings, you can reproduce the original BSP while ensuring that system-dependent settings are adjusted correctly based on any changes in the hardware system.

For more information about Tcl scripting with the SBT, refer to the “Tcl Scripts for BSP Settings”.

For more information, refer to “Getting Started with Nios II Software in Eclipse” and “Using the BSP Editor” in the Getting Started with the Graphical User Interface section.

The nios2-bsp-create-settings command does not apply default settings to your BSP. However, you can use the --script command-line option to run the default Tcl script.

For more information about the default Tcl script, refer to the “Specifying BSP Defaults” chapter.

For more information about using the nios2-bsp-create-settings command, refer to the "Nios II Software Build Tools Reference" chapter.

The top level Tcl script for setting BSP defaults is bsp-set-defaults.tcl. This script specifies BSP system-dependent settings, which depend on the hardware system. The nios2-bsp-create-settings and nios2-bsp-update-settings utilities do not call the default Tcl script when creating or updating a BSP settings file. The --script option must be used to specify bsp-set-defaults.tcl explicitly. Both the Nios II SBT for Eclipse and the nios2-bsp script call the default Tcl script by invoking either nios2-bsp-create-settings or nios2-bsp-update-settings with the --script bsp-set-defaults.tcl option.

The default Tcl script consists of a top-level Tcl script named bsp-set-defaults.tcl plus the helper Tcl scripts listed in the "Default Tcl Script Components" table (Table 4–9). The helper Tcl scripts do the real work of examining the .sopcinfo file and choosing appropriate defaults.

The bsp-set-defaults.tcl script sets the following defaults:

• stdio character device (bsp-stdio-utils.tcl)
• System timer device (bsp-timer-utils.tcl)
• Default linker memory regions (bsp-linker-utils.tcl)
• Default linker sections mapping (bsp-linker-utils.tcl)
• Default boot loader settings (bsp-bootloader-utils.tcl)

You run the default Tcl script on the nios2-bsp-create-settings, nios2-bsp-query-settings, or nios2-bsp-update-settings command line, by using the --script argument. It has the following usage:

bsp-set-defaults.tcl [<argument name> <argument value>]*

All arguments are optional. If present, each argument must be in the form of a name and argument value, separated by white space. All argument values are strings. For any argument not specified, the corresponding helper script chooses a suitable default value. In every case, if the argument value is DONT_CHANGE, the default Tcl scripts leave the setting unchanged. The DONT_CHANGE value allows fine-grained control of what settings the default Tcl script changes and is useful when updating an existing BSP.

For more information about these settings, refer to the Nios II Software Build Tools Reference section.

The script searches the .sopcinfo file for a slave descriptor with the string stdio in its name. If bsp-stdio-utils.tcl finds any such slave descriptors, it chooses the first as the default stdio device. If the script finds no such slave descriptor, it looks for a slave descriptor with the string jtag_uart in its component class name. If it finds any such slave descriptors, it chooses the first as the default stdio device. If the script finds no slave descriptors fitting either description, it chooses the last character device slave descriptor connected to the Nios II processor. If bsp-stdio-utils.tcl does not find any character devices, there is no stdio device.

For more information about this setting, refer to the Nios II Software Build Tools Reference section.

The script searches the .sopcinfo file for a timer component to use as the default system timer. To be an appropriate system timer, the component must have the following characteristics:

• It must be a timer, that is, is_timer_device must return true.
• It must have a slave port connected to the Nios II processor.

When the script finds an appropriate system timer component, it sets hal.sys_clk_timer to the timer slave port descriptor. The script prefers a slave port whose descriptor contains the string sys_clk, if one exists. If no appropriate system timer component is found, the script sets hal.sys_clk_timer to none.

For more information about these commands, refer to the Nios II Software Build Tools Reference section.

The script chooses the largest volatile memory region as the default memory region. If there is no volatile memory region, bsp-linker-utils.tcl chooses the largest non-volatile memory region. The script assigns the .text, .rodata, .rwdata, .bss, .heap, and .stack section mappings to this default memory region. The script also sets the hal.linker.exception_stack_memory_region BSP setting to the default memory region. The setting is available in case the separate exception stack option is enabled (this setting is disabled by default).

For more information about this setting, refer to the Nios II Software Build Tools Reference section.

• hal.linker.allow_code_at_reset
• hal.linker.enable_alt_load_copy_rodata
• hal.linker.enable_alt_load_copy_rwdata
• hal.linker.enable_alt_load_copy_exceptions

For more information about these settings, refer to the Nios II Software Build Tools Reference section.

The script examines the .text section mapping and the Nios II reset slave port. If the .text section is mapped to the same memory as the Nios II reset slave port and the reset slave port is a flash memory device, the script assumes that a boot loader is being used. You can override this behavior by passing the enable_bootloader option to the default Tcl script.

If a boot loader is enabled, the assumption is that the boot loader is located at the reset address and handles the copying of sections on reset. If there is no boot loader, the BSP might need to provide code to handle these functions. You can use the alt_load() function to implement a boot loader.

The default Tcl script consists of the top-level bsp-call-proc.tcl script plus the helper scripts listed in the "Default Tcl Script Components" table (Table 4–9 on page 4–33). The procedure call Tcl script allows you to call a specific procedure in the helper scripts, if you want to invoke some of the default Tcl functionality without running the entire default Tcl script.

The procedure call Tcl script has the following usage:

bsp-call-proc.tcl <proc-name> [<args>]*

bsp-call-proc.tcl calls the specified procedure with the specified (optional) arguments. Refer to the default Tcl scripts to view the available functions and their arguments. The bsp-call-proc.tcl script includes the same files as the bsp-set-defaults.tcl script, so any function in those included files is available.

The IsFlash property of the memory module (defined in the .sopcinfo file) indicates whether the .sopcinfo file identifies the memory as a flash memory device. The IsNonVolatileStorage property indicates whether the .sopcinfo file identifies the memory as a non-volatile storage device. The contents of a non-volatile memory device are fixed and always present.

The following sections describe each supported build configuration in detail. The alt_load() facility is HAL code that optionally copies sections from the boot memory to RAM. You can set an option to enable the boot copy. This option only adds the code to your BSP if it needs to copy boot segments. The hal.enable_alt_load setting enables alt_load() and there are settings for each of the three sections it can copy (such as hal.enable_alt_load_copy_rodata). Enabling alt_load() also modifies the memory layout specified in your linker script.

This boot configuration has the following characteristics:

• alt_load() not called
• No code at reset in executable file

The default Tcl script chooses this configuration when the memory associated with the processor reset address is a flash memory and the .text section is mapped to a different memory (for example, SDRAM).

Intel FPGA provides example boot loaders for CFI and EPCS memory in the Nios II EDS, precompiled to Motorola S-record Files (.srec). You can use one of these example boot loaders, or provide your own.

This boot configuration has the following characteristics:

• alt_load() not called
• No code at reset in executable file

The default Tcl script assumes no boot loader is in use, so it chooses this configuration only if you enable it. To enable this configuration, pass the following argument to the default Tcl script:enable_bootloader 1

If you are using the nios2-bsp script, call it as follows:

The reset address points to the beginning of the application in memory (no boot loader). The reset memory must have its contents initialized before the processor comes out of reset. The initialization might be implemented by using a non-volatile reset memory (for example, flash, ROM, initialized FPGA RAM) or by an external master (for example, another processor) that writes the reset memory. The HAL C run-time startup code (crt0) initializes the instruction cache, uses alt_load() to copy select sections to their VMAs, and then jumps to _start. For each associated section (.rwdata, .rodata, .exceptions), boolean settings control this behavior. The default Tcl scripts set these to default values as described in the "Boot Loader-Dependent Settings" table (Table 4–11 on page 4–36).

alt_load() must copy the .rwdata section (either to another RAM or to a reserved area in the same RAM as the .text RAM) if .rwdata needs to be correct after multiple resets.

This boot configuration has the following characteristics:

• alt_load() called
• Code at reset in executable file

The default Tcl script chooses this configuration when the reset and .text memory are the same.

In this boot configuration, when the processor core resets, by default the .rwdata section is not reinitialized. Reinitialization would normally be done by a boot loader. However, this configuration has no boot loader, because the software is running out of memory that is assumed to be preinitialized before startup.

If your software has a .rwdata section that must be reinitialized at processor reset, turn on the hal.linker.enable_alt_load_copy_rwdata setting in the BSP.

This boot configuration has the following characteristics:

• alt_load() might be called (depends on boot configuration)
• No code at reset in executable file

Because the processor reset address points to an additional memory, the algorithms used by the default Tcl script to select the appropriate boot configuration might make the wrong choice. The individual BSP settings specified by the default Tcl script need to be explicitly controlled.

• The Nios II SBT for Eclipse
• The Nios II BSP Editor
• The Nios II Flash Programmer

For more information about how each GUI is primarily a thin layer providing graphical control of the command-line tools, refer to “The Nios II Command-Line Commands” chapter.

You can launch the Nios II SBT for Eclipse either of the following ways:

• In the Windows operating system, on the Start menu, point to Programs > Altera > Nios II EDS <version>, and click Nios II <version> Software Build Tools for Eclipse.
• From the Nios II Command Shell, by typing eclipse-nios2.

For more information about the Nios II SBT for Eclipse, refer to the Getting Started with the Graphical User Interface section.

• From the Nios II menu in the Nios II SBT for Eclipse
• From the Nios II Command Shell, by typing nios2-bsp-editor.

The Nios II BSP Editor enables you to edit settings, linker regions, and section mappings, and to select software packages and device drivers.

The capabilities of the Nios II BSP Editor constitute a large subset of the capabilities of the nios2-bsp-create-settings, nios2-bsp-update-settings, and nios2-bsp-generate-files utilities. Any project created in the BSP Editor can also be created using the command-line utilities.

For more information about the BSP Editor, refer to “Using the BSP Editor” in the Getting Started with the Graphical User Interface section.

• Executable code and data
• Bootstrap code to copy code from flash to RAM, and then run from RAM
• HAL file subsystems
• FPGA hardware configuration data

You can launch the flash programmer either of the following ways:

• From the Nios II menu in the Nios II SBT for Eclipse
• From the Nios II Command Shell, by typing:

  nios2-flash-programmer-generate

The Nios II EDS includes version GCC 4.8.3 of the GCC toolchain.

For more information about installing the Altera Complete Design Suite, refer to the Altera Software Installation and Licensing Manual.

The following options are new for the GCC toolchain:

Code density and performance

Use of the -mgpopt=global setting is recommended as it generally deliver results with better code density *and* performance. (Note: this requires that everything is compiled with the same -Gn switch setting; use of -Gn is not generally recommended).

C++ code size reduction: -fno-exceptions

When a developer is using C++ but trying not to link in the (big) C++ exception-handling machinery nios2-elf-g++ will, in some cases, link in the exception-handling machinery where it is not actually required. This switch suppresses that behaviour, which results in a smaller code footprint for those situations.

Response to address 0x00 access: -fdelete-null-pointer-checks

Developers often have RAM at address 0x00 (== NULL pointer in gcc and most C compilers). From gcc 4.9 onwards, by default gcc detects attempts to read or write to address 0x00 and converts them to traps; typically in embedded/Nios II-based systems, these traps are not handled so the code will fail silently. This means that code that works when compiled with earlier versions of gcc could silently fail when compiled with gcc-4.9 (onwards).

In order to avoid this for Nios II this behaviour has been modified so that accesses to address 0x00 will work as expected for Nios II systems but there may be a slight negative effect on code performance. In Nios II systems that are known not to read/write RAM at address 0x00, use of the switch --fdelete-null-pointer-checks restores the original gcc behaviour and may provide a small performance boost.

Expansion of __builtin_trap

The latest versions of GCC now produce trap 3 instead of break 3 in the expansion of the __builtin_trap function and in other situations where a trap is emitted to indicate undefined runtime behaviour. This is for compliance with the Nios II ABI for Linux targets, which does not permit the use of the break instruction in user code.

GDB breakpoint instruction

GDB now uniformly uses trap 31 instead of a break instruction for software breakpoints. This is for consistency with the Nios II ABI for Linux targets.

GNU tools for the Nios II processor are generally named nios2-elf-<tool name>. The following list shows some examples:

• nios2-elf-gcc
• nios2-elf-as
• nios2-elf-ld
• nios2-elf-objdump
• nios2-elf-size

The exception is the make utility, which is simply named make.

The Nios II GNU tools reside in the following location:

• <Nios II EDS install path>/bin/gnu directory

Refer to the following additional sources of information:

• For more information about managing GCC toolchains in the SBT for Eclipse— “Managing Toolchains in Eclipse” in the "Getting Started with the Graphical User Interface" chapter.
• For more information about selecting the toolchain on the command line—the "Getting Started from the Command Line" chapter.
• For more information about a comprehensive list of Nios II GNU tools—the GNU HTML documentation, refer to the Nios II Embedded Design Suite Support page on the Intel FPGA website.
• For more information about GNU, refer to the Free Software Foundation website.

You can call these utilities and scripts on the command line or from the scripting language of your choice (such as perl or bash).

The Nios II SBT utilities reside in the <Nios II EDS install path>/sdk2/bin directory.

For more information about the Nios II SBT, refer to the "Getting Started from the Command Line" chapter.

The file format conversion tools are in the <Nios II EDS install path>/bin/ directory.

Description

The bin2flash utility converts any binary data file to a FLASH file that can be used by the flash programmer.

Usage

bin2flash [--debug] [--silent] [--help] [--log=file]
       [--location=addr] [--quiet] [--input=file] [--verbose] [--output=file]

Options

    --debug             debug mode
    --help              print this message
    --input=<file>      input Binary file to process
    --location=<addr>   design location within the flash
    --log=<file>        file for logging progress
    --output=<file>     output flash file
    --quiet             only print errors
    --silent            silent mode - same as quiet
    --verbose           lots of interesting information

Description

Converts a .elf file to a .dat file format appropriate for Verilog HDL hardware simulators.

Usage

elf2dat --infile=file --outfile=file --width=width --base=address
               --end=address [--pad=number] [--create-lanes=number]
               [--little-endian-mem] [--big-endian-mem]

Options

   --infile=<elf-input-filename>
    --outfile=<dat-output-filename>
    --base=<base address>
    --end=<end address>
    --pad=[0 | 1] (default 1)
    --create-lanes=[0 | 1] (default 0)
    --width=[ 8 | 16 | 32 | 64 | 128]
    --little-endian-mem
    --big-endian-mem

Transforms the data within an ELF file in the address range [base, end] into the corresponding DAT file. Lane files are optionally created (--create-lanes=1, default is 0). Lane file names are generated based on the output file by inserting "_lane0", "_lane1", etc. before the ".dat" extension of the output filename. If "--pad=1" is specified, any unspecified locations in memory will be filled with zeros. If "--little-endian-mem" is specified, the memory is assumed to be little-endian. If "--big-endian-mem" is specified, the memory is assumed to be big-endian. If neither --little-endian-mem or --big-endian-mem is specified, the memory is assumed to be little-endian. Note that the endianness of the ELF file never effects the result.

Example

elf2dat --infile=foo.elf --outfile=bar.dat --width=32 --create-lanes=1
            --base=0 --end=0x1000

will create DAT files bar.dat, bar_lane0.dat, bar_lane1.dat, bar_lane2.dat, bar_lane3.dat

Description

The elf2flash utility takes a software file in ELF format and translates it to a FLASH file that can be programmed into the flash memory connected to an Altera FPGA.

Usage

elf2flash [--boot=file] [--debug] [--base=addr] [--save]
       [--quiet] [--epcs] [--end=addr] [--verbose] [--silent] [--help]
       [--log=file] [--after[=file]] [--input=file] [--reset=addr]
       [--offset=offset] [--sim_optimize[=value]] [--output=file]

Options

    --after[=<file>]           Start output at address immediately
                               following data in specified .flash file
    --base=<addr>              flash base address
    --boot=<file>              boot copier SREC file
    --debug                    debug mode
    --end=<addr>               flash end address
    --epcs                     epcs flash mode
    --help                     print this message
    --input=<file>             input ELF file to process
    --log=<file>               file for logging progress
    --offset=<offset>          EPCS offset
    --output=<file>            output flash file
    --quiet                    only print errors
    --reset=<addr>             CPU reset address
    --save                     save intermediate files
    --silent                   silent mode - same as quiet
    --sim_optimize[=<value>]   Optimize for simulation
    --verbose                  lots of interesting information

The elf2flash utility converts the software and data within an ELF file in the address range [base, end] into a FLASH file. This utility can also optionally insert a boot copier into the FLASH file to copy the software from flash memory to RAM before running it.

Description

The elf2hex utility takes a software file in ELF format and translates it to a HEX file that can be used as the initialization data for a memory component.

Usage

elf2hex [--debug] [--record=length] [--base=addr] [--quiet]
       [--width=value] [--big-endian-mem] [--no-zero-fill]
       [--create-lanes[=value]] [--lower] [--end=addr] [--verbose] [--silent]
       [--help] [--log=file] [--input=file] [--little-endian-mem]
       [--output=file]

Options

--base=<addr>              Hex data base address
    --big-endian-mem           Force big-endian memory layout
    --create-lanes[=<value>]   1 if lane files should be created
    --debug                    debug mode
    --end=<addr>               Hex data end address
    --help                     print this message
    --input=<file>             input ELF file to process
    --little-endian-mem        Force little-endian memory layout
    --log=<file>               file for logging progress
    --lower                    If you prefer your hex in lower case
    --no-zero-fill             No zero fill of empty sections
    --output=<file>            output Hex file
    --quiet                    only print errors
    --record=<length>          Output record length, in bytes.
    --silent                   silent mode - same as quiet
    --verbose                  lots of interesting information
    --width=<value>            [ 8 | 16 | 32 | 39 | 64 | 128]

The elf2hex utility converts the software and data within an ELF file in the address range [base, end] into a HEX file. The width option is used to insure that the resulting HEX file is formatted properly for its corresponding memory component. This utility can also create lane files which are used to initialize multi-laned memory components.

Description

elf2-h transforms the data within an elf file in the address range [low, high] into the corresponding -H file. Lane files are optionally created (--create-lanes=1, default is 0). Lane file names are generated based on the output file by inserting "_lane0", "_lane1", etc. before the ".-h" extension of the output filename.

Usage

elf2-h elf_file [low_address  high_address] [--width=width]
                [--create-lanes=lanes] [-h_file]

Options

elf_file               the elf input file
    low address            beginning of the range to transform
    high address           end of the range to transform
    --width=width          [ 8 | 16 | 32 | 64 | 128]
    --create-lanes=lanes   [0 | 1] (default 0)
    -h_file               the -H file to create

Example

elf2-h foo.elf 0 0x0FFF --width=32 --create_lanes=1 bar.-h

will create -H files—bar.-h, bar_lane0.-h, bar_lane1.-h, bar_lane2.-h, and bar_lane3.-h

Description

Converts an SRAM Object File (.sof) to a .flash file.

Usage

flash2dat --infile=<flash-input-filename>
                 --outfile=<dat-output-filename>
                 --width=[ 8 | 16 | 32 | 39 | 64 | 128]
                 --base=<base byte-address of range of interest>
                 --end=<last byte-address of range of interest>
                 --pad=<1 if all locations should be represented in output>
                 --create-lanes=<1 if lane files should be created>
                 --relocate-input=<input-data relocation offset (usually=base)>
                 [--little-endian-mem] [--big-endian-mem]

Example

flash2dat --infile=foo.flash --outfile=foo.dat --width=32 --base=0x1000000 \
    --end=0x1000FFF --pad=1 --create-lanes=1 --relocate=0x1000000

Creates files foo.dat, foo_lane0.dat, foo_lane1.dat, foo_lane2.dat and foo_lane3.dat. foo.dat contains 4K bytes of data, padded with 0 where data was not present in the .flash file. foo_lane[0123].dat each contain 1K bytes of data from their respective byte lanes. The input .flash file data should be relocated by 0x1000000 to correspond to the specified --base address.

Description

The sof2flash utility takes an FPGA configuration file in SOF format and translates it to a FLASH file that can be programmed into the flash memory connected to an FPGA.

Usage

sof2flash [--programmingmode=programmingmode] [--debug]
       [--optionbit=optionbitaddress] [--save] [--quiet] [--pfl] [--epcs]
       [--epcq128] [--epcq] [--verbose] [--activeparallel] [--timestamp]
       [--help] [--log=file] [--input=file] [--offset=addr] [--compress]
       [--options=file] [--output=file]

Options

    --activeparallel                      create parallel flash contents
                                          for active parallel programming
    --compress                            compress the SOF
    --debug                               debug mode
    --epcq                                EPCQ flash mode of size
                                          256Mbits
    --epcq128                             EPCQ flash mode of size
                                          128Mbits or less
    --epcs                                EPCS flash mode
    --help                                print this message
    --input=<file>                        input SOF file to process
    --log=<file>                          file for logging progress
    --offset=<addr>                       design location within the
                                          flash
    --optionbit=<optionbitaddress>        Option Bit Address
    --options=<file>                      intermediate Options file (for
                                          EPCS only)
    --output=<file>                       output flash file
    --pfl                                 Pfl mode
    --programmingmode=<programmingmode>   Programming mode
    --quiet                               only print errors
    --save                                save intermediate files
    --timestamp                           produce a s0 record with
                                          timestamp of input file
    --verbose                             lots of interesting
                                          information

The command-line tools described in this section are in the <Nios II EDS install path>/bin/ directory.

Description

This tool prepares a target system for debugging, it checks that the hardware and software are compatible, downloads the software and optionally makes the target processor run the downloaded code.

Usage

nios2-download [-h/--help] [-C/--directory <dir name>]
       [-c/--cable <cable name>] [-d/--device <device index>]
       [-i/--instance <instance>] [-r/--reset-target]        
       [-s/--sidp <address> -I/--id <id> -t/--timestamp <timestamp>]
       [--accept-bad-sysid] [-w/--wait <seconds>] [-g/--go] [--stop]
           [--tcpport <port> | auto] [--write-gmon <file>]          
           [--jdi <file>] [--cpu_name <name>]                       
           [<filename>]      

Options

 -h/--help                   Prints this message.

 -C/--directory <dir name>   Change to this directory before running

 -c/--cable <cable name>     Specifies which JTAG cable to use (not needed if
                             you only have one cable).                       
 -d/--device <device index>  Specifies in which device you want to look for the
                             Nios II CPU (1 = device nearest TDI etc.)         
 -i/--instance <instance>    Specifies the INSTANCE value of the Nios II CPU   
                             JTAG debug module (auto-detected if you specify   
                             an ELF file or use --directory to point to one)   

 -r/--reset-target           Reset the target SOPC system before use.

 -s/--sidp <address>         Base-address of System ID peripheral on target
                             This base-address must be specified in hex (0x...)
 -I/--id <system-id-value>   Unique ID code for target system
 -t/--timestamp <time-stamp> Timestamp for target-system (when last generated)
    --accept-bad-sysid       Continue even if the system ID comparison fails

 <filename.elf>              An ELF file to download to the target

 -w/--wait <seconds>         Wait for time specified before starting processor
 -g/--go                     Run processor from entry point after downloading.
    --stop                   Stop processor (leave it in a paused state).
    --tcpport <port> | auto  Listen on specified TCP port for a connection from
                             GDB (with "auto" a free port will be used).
    --write-gmon <file>      Write profiling data to the file specified when the
                             target exits.
    --jdi <file>            Specify which .jdi file to read the INSTANCE
                             value of the Nios II CPU JTAG debug module from.
                             (if not specified, will look in the same folder
                             as the .ptf file, as specified in generated.sh)
    --cpu_name <name>        CPU module name to use when trying to scan for
                             INSTANCE value from the .jdi file.  Will use the
                             name specified in generated.sh if it is not passed
                             in.
                    NOTE:    nios2-download needs a .jdi file and a cpu_name
                             to search for the INSTANCE value.  This can be
                             supplied via the command line, or will be searched
                             for with information from generated.sh

If you specify the --go option then the target processor will be started before this tool exits. If --go is not specified but a file is downloaded or the target processor needs to be reset then it will be left in the paused state. Otherwise the target processor state will be left unchanged unless --stop is specified (in which case it will be paused). Return codes are: 0 for success; 1 if the system ID did not match; 2 if no Nios II CPUs are found; a return code of 4 or more indicates an error which will need manual intervention to solve.

Description

The nios2-flash-programmer-generate command will convert multiple files to the .flash format and then program them to the designated target flash devices (--program-flash). This is a convenience utility that manages calls to the following command line utilities: bin2flash, elf2flash, sof2flash, and nios2-flash-programmer. This utility also generates a convenience shell script that captures the sequence of conversion and flash programmer command line tool expressions.

Usage

nios2-flash-programmer-generate --sopcinfo <filename> --flash-dir
<filepath> [<options>]                                                  

Options

--flash-dir <filepath>  Path to the directory where the flash files are
                        generated. Use . for the current directory. This
                        command overwrites pre-existing files in <filepath>
                        without warning.                                   

--sopcinfo <filename>   The SOPC Builder system file (.sopcinfo).

Optional Arguments:

--accept-bad-sysid      Continue even if the system ID comparison fails

--add-bin <fname> <flash-slave-desc> <offset>  Specify an bin file to
                        convert and program. The filename, target flash slave
                        descriptor, and target offset amount are required.   
                        This option can be used multiple times for .sof files.

--add-elf <fname> <flash-slave-desc> <extra-elf2flash-arguments>   
                        Specify an elf file to convert and program. The
                        filename, and target flash slave descriptor are
                        required. This option can be used multiple times for
                        .elf files. The [<extra-elf2flash-arguments>] can   
                        be any of these options supported by 'elf2flash':   
                        'save', 'sim_optimize'. The 'elf2flash' options:    
                        'base', 'boot', 'end', 'reset' have default values  
                        computed, but are also supported as                 
                        [<extra-elf2flash-arguments>] for manual override   
                        of those defaults. Do not prepend extra arguments with
                        '--'.                                                 

--add-sof <fname> <flash-slave-desc> <offset> <extra-sof2flash-arguments>   
                        Specify an sof file to convert and program. The     
                        filename, target flash slave descriptor, and target 
                        offset amount are required. This option can be used 
                        multiple times for .sof files. The                  
                        [<extra-sof2flash-arguments>] can be any of these   
                        options supported by 'sof2flash':                   
                        'activeparallel', 'compress', 'save',               
                        'timestamp'. Do not prepend extra arguments with    
                        '--'.                                               

--cable <cable name>    Specifies which JTAG cable to use (not needed if you
                        only have one cable). Not used without              
                        --program-flash option                              

--cpu <cpu name>        The SOPC Builder system file Nios II CPU name. Not
                        required if only one Nios II CPU in the system.   

--debug                 Sends debug information, exception traces, verbose
                        output, and default information about the command's
                        operation, to stdout.                              

--device <device name>  Specifies in which device you want to look for the Nios
                        II debug core ('1' is device nearest TDI etc.). Not used
                        without --program-flash option                          

--erase-first           Erase entire flash targets before programming them.
                        Not used without --program-flash option            

--extended-help         Displays full information about this command and its
                        options.                                            

--go                    Run processor from reset vector after program.

--help                  Displays basic information about this command and its
                        options.                                             

--id <address>          Unique ID code for target system. Not used without
                        --program-flash option                            

--instance <instance value> Specifies the INSTANCE value of the debug core (not
                        needed if there is exactly one on the chain). Not used 
                        without --program-flash option                         

--jvm-max-heap-size <value> Optional. The maximum memory size to be used for
                        allocations when running this tool. This value is   
                        specified as <size><unit> where unit can be m (or M) for
                        multiples of megabytes or g (or G) for multiples of     
                        gigabytes. The default value is 512m.                   

--log <filename>        Creates a debug log and write to specified file. Also
                        logs debug information to stdout.

--mmu                   Specifies if the CPU with the corresponding INSTANCE
                        value has an MMU (not needed if there is exactly one CPU
                        in the system). Not used without --program-flash
                        option

--program-flash         Providing this flag causes calls to
                        nios2-flash-programmer to be generated and
                        executed. This results in flash targets being
                        programmed.

--script-dir <filepath> Path to the directory where a shell script of this tools
                        executed command lines is generated. This convenient
                        script can be used in place of this
                        'nios2-flash-programmer-generate' command. Use .
                        for the current directory. This command overwrites
                        pre-existing files in <filepath> without warning.

--sidp <address>        Base-address of System ID peripheral on target. Not
                        used without --program-flash option

--silent                Suppresses information about the command's
                        operation normally sent to stdout.

--timestamp <time-stamp>Timestamp for target-system (when last generated).

--verbose               Sends verbose output, and default information about
                        the command's operation, to stdout.

--version               Displays the version of this command and exits with a
                        zero exit status.

Description

Programs data to flash memory on the target board.

Usage

nios2-flash-programmer [-h/--help] [-c/--cable <cable name>]
       [-d/--device <device index>] [-i/--instance <instance>]     
       [-s/--sidp <address>] [-I/--id <id>] [-t/--timestamp <timestamp>]
       -b/--base <address> [-e/--epcs]                                  
       <action> [-g/--go] [--dualdie]  

Options

-h/--help                   Print this message
 -Q/--quiet                  Don't print anything if everything works
    --debug                  Print debug information

 -c/--cable <cable name>     Specifies which JTAG cable to use (not needed if
                             you only have one cable)
 -d/--device <device index>  Specifies in which device you want to look for the
                             Nios II debug core (1 = device nearest TDI etc.)
 --dualdie                   Force override the die size to be dual die.
 -i/--instance <instance>    Specifies the INSTANCE value of the debug core
                             (not needed if there is exactly one on the chain)

 -s/--sidp <address>         Base-address of System ID peripheral on target
 -I/--id <system-id-value>   Unique ID code for target system
 -t/--timestamp <time-stamp> Timestamp for target-system (when last generated)
    --accept-bad-sysid       Continue even if the system ID comparison fails

 -b/--base <address>         Base address of FLASH/EPCS to operate on
 -e/--epcs                   This operation is on an EPCS flash
 -M/--mmu                    MMU present in the Nios II cpu.
 -E/--erase <start>+<size>   Erase a range of bytes in the flash, or the entire
    --erase-all              flash before/instead of programming it.
 -P/--program                Program flash from the input files (the default)
    --no-keep-nearby         Don't preserve bytes which need to be erased but
                             which aren't specified in the input file
 -Y/--verify                 Verify that contents of flash match input files
 <filename>*                 The names of the file(s) to program or verify

 -R/--read <file>            Read flash contents into file
 -B/--read-bytes <start>+<size> Specify which bytes to read

 -g/--go                     Run processor from reset vector after program.

Input files should be in Motorola S-Record format. Addresses within the files are interpreted as offsets from the base address of the flash. Output files written by the tool are in the same format. The flash programmer supports all CFI flashes which use the AMD programming algorithm (CFI algorithm 2) or the Intel algorithm (1 or 3).

Description

Programs data to flash memory on the target board.

Usage

nios2-flash-programmer [-h/--help] [-c/--cable <cable name>]
       [-d/--device <device index>] [-i/--instance <instance>]     
       [-s/--sidp <address>] [-I/--id <id>] [-t/--timestamp <timestamp>]
       -b/--base <address> [-e/--epcs]                                  
       <action> [-g/--go] [--dualdie]  

Options

-h/--help                   Print this message
 -Q/--quiet                  Don't print anything if everything works
    --debug                  Print debug information

 -c/--cable <cable name>     Specifies which JTAG cable to use (not needed if
                             you only have one cable)
 -d/--device <device index>  Specifies in which device you want to look for the
                             Nios II debug core (1 = device nearest TDI etc.)
 --dualdie                   Force override the die size to be dual die.
 -i/--instance <instance>    Specifies the INSTANCE value of the debug core
                             (not needed if there is exactly one on the chain)

 -s/--sidp <address>         Base-address of System ID peripheral on target
 -I/--id <system-id-value>   Unique ID code for target system
 -t/--timestamp <time-stamp> Timestamp for target-system (when last generated)
    --accept-bad-sysid       Continue even if the system ID comparison fails

 -b/--base <address>         Base address of FLASH/EPCS to operate on
 -e/--epcs                   This operation is on an EPCS flash
 -M/--mmu                    MMU present in the Nios II cpu.
 -E/--erase <start>+<size>   Erase a range of bytes in the flash, or the entire
    --erase-all              flash before/instead of programming it.
 -P/--program                Program flash from the input files (the default)
    --no-keep-nearby         Don't preserve bytes which need to be erased but
                             which aren't specified in the input file
 -Y/--verify                 Verify that contents of flash match input files
 <filename>*                 The names of the file(s) to program or verify

 -R/--read <file>            Read flash contents into file
 -B/--read-bytes <start>+<size> Specify which bytes to read

 -g/--go                     Run processor from reset vector after program.

Input files should be in Motorola S-Record format. Addresses within the files are interpreted as offsets from the base address of the flash. Output files written by the tool are in the same format. The flash programmer supports all CFI flashes which use the AMD programming algorithm (CFI algorithm 2) or the Intel algorithm (1 or 3).

Description

Translates GNU debugger (GDB) remote serial protocol packets over Transmission Control Protocol (TCP) to JTAG transactions with a target Nios II processor.

Usage

nios2-gdb-server [-h/--help] [-c/--cable <cable name>]
       [-d/--device <device index>] [-i/--instance <instance>]
       [-s/--sidp <address>] [-I/--id <id>] [-t/--timestamp <timestamp>]
       [-w/--wait <seconds>] [--no-verify] [-g/--go] [--stop]           
       [--tcpport=<port> | auto] [--tcpdebug] [--tcptimeout <seconds>]  
       [--tcppersist] [--thread-vars <vars>]                            
       [--write-gmon <gmonfile>] [--wait-target-exit]                   
       <filename.srec>*         

Options

-h/--help                   Print this message

    --write-pid <filename>   Write the process ID to the file specified
    --signal-pid <filename>  Send a SIGUSR1 to the other process when ready

 -c/--cable <cable name>     Specifies which JTAG cable to use (not needed if
                             you only have one cable)                        
 -d/--device <device index>  Specifies in which device you want to look for the
                             Nios II OCI core (1 = device nearest TDI etc.)
 -i/--instance <instance>    Specifies the INSTANCE value of the JTAG debug core
                             (not needed if there is exactly one on the chain)

 -r/--reset-target           Always reset the target system before use

 -C/--init-cache             Always initialize target processor cache before use

 -s/--sidp <address>         Base-address of System ID peripheral on target
 -I/--id <system-id-value>   Unique ID code for target system
 -t/--timestamp <time-stamp> Timestamp for target-system (when last generated)
    --accept-bad-sysid       Continue even if the system ID comparison fails

 <filename.srec>*            S-Record file(s) to download to the target
    --no-verify              Don't verify after downloading

 -w/--wait <seconds>         Wait for time specified before starting processor
                             (signal USR1 will terminate the wait early)
 -g/--go                     Run processor from entry point after downloading
    --stop                   Stop processor (leave it in a paused state).

    --tcpport <port> | auto  Listen on specified TCP port for a connection from
                             GDB (with "auto" a free port will be used).
    --tcpdebug               Display the GDB remote protocol running over TCP
    --tcptimeout <seconds>   Timeout if GDB has not connected in time specified
    --tcppersist             Don't stop when GDB disconnects
    --thread-vars <vars>     Decode target thread list using specified string

    --write-gmon <gmonfile>  Wait for target to complete and write GMON data
                             (if available) to the file specified
    --wait-target-exit       Wait for target to complete and return target exit
                             code as our return code if no other errors

Description

Translates GNU debugger (GDB) remote serial protocol packets over Transmission Control Protocol (TCP) to JTAG transactions with a target Nios II processor.

Usage

nios2-gdb-server [-h/--help] [-c/--cable <cable name>]
       [-d/--device <device index>] [-i/--instance <instance>]
       [-s/--sidp <address>] [-I/--id <id>] [-t/--timestamp <timestamp>]
       [-w/--wait <seconds>] [--no-verify] [-g/--go] [--stop]           
       [--tcpport=<port> | auto] [--tcpdebug] [--tcptimeout <seconds>]  
       [--tcppersist] [--thread-vars <vars>]                            
       [--write-gmon <gmonfile>] [--wait-target-exit]                   
       <filename.srec>*         

Options

-h/--help                   Print this message

    --write-pid <filename>   Write the process ID to the file specified
    --signal-pid <filename>  Send a SIGUSR1 to the other process when ready

 -c/--cable <cable name>     Specifies which JTAG cable to use (not needed if
                             you only have one cable)                        
 -d/--device <device index>  Specifies in which device you want to look for the
                             Nios II OCI core (1 = device nearest TDI etc.)
 -i/--instance <instance>    Specifies the INSTANCE value of the JTAG debug core
                             (not needed if there is exactly one on the chain)

 -r/--reset-target           Always reset the target system before use

 -C/--init-cache             Always initialize target processor cache before use

 -s/--sidp <address>         Base-address of System ID peripheral on target
 -I/--id <system-id-value>   Unique ID code for target system
 -t/--timestamp <time-stamp> Timestamp for target-system (when last generated)
    --accept-bad-sysid       Continue even if the system ID comparison fails

 <filename.srec>*            S-Record file(s) to download to the target
    --no-verify              Don't verify after downloading

 -w/--wait <seconds>         Wait for time specified before starting processor
                             (signal USR1 will terminate the wait early)
 -g/--go                     Run processor from entry point after downloading
    --stop                   Stop processor (leave it in a paused state).

    --tcpport <port> | auto  Listen on specified TCP port for a connection from
                             GDB (with "auto" a free port will be used).
    --tcpdebug               Display the GDB remote protocol running over TCP
    --tcptimeout <seconds>   Timeout if GDB has not connected in time specified
    --tcppersist             Don't stop when GDB disconnects
    --thread-vars <vars>     Decode target thread list using specified string

    --write-gmon <gmonfile>  Wait for target to complete and write GMON data
                             (if available) to the file specified
    --wait-target-exit       Wait for target to complete and return target exit
                             code as our return code if no other errors

Description

Performs terminal I/O with a JTAG UART in a Nios II system.

Usage

nios2-terminal [TERMINAL OPTIONS] [CONNECTION OPTIONS] [TARGET OPTIONS]

Options

Terminal Options

  -V, --version              display version number
  -h, --help                 show this message and exit
  -v, --verbose              show extra information during run (default)
  -q, --quiet                show minimal information                   
      --write-pid            write process ID to filename specified
  -w, --wait                 wait for a signal before starting
      --flush                empty buffers before displaying output
      --signal-pid           send signal to process ID when ready
  -o, --quit-after=SECS      quit after SECS second(s) (default is never)
      --no-quit-on-ctrl-d    don't quit if Ctrl-D received from target
  -u, --dump=OPTS            dump extra debug information for OPTS
      --gmon                 write gmon.out file if seen from target
      --no-gmon              do not write gmon.out

Connection Options

  -H, --hardware             connect to a hardware target (default)
  -I, --iss                  launch and connect to iss target
  -M, --modelsim             connect to a modelsim target
  -U, --uart                 connect to hardware using a UART
      --persistent           try to reconnect after an I/O error
      --no-persistent        opposite of persistent

Connect to Hardware Options

-c, --cable=CABLE          use CABLE JTAG cable (default auto-detect)
  -d, --device=DEVICE        connect to DEVICE device (default auto-detect)
  -i, --instance=INSTANCE    connect to INSTANCE instance (default auto-detect)

Launch and Connect to ISS Options

  -f, --elf=FILE             launch ISS with FILE in simulation memory
  -p, --ptf=FILE             launch ISS with FILE as system description
  -g, --debug                launch ISS in debug mode waiting for
                              gdb connection at reset or entry point
  -r, --no-debug             launch ISS in run mode
  -a, --iss-arg=ARG          pass additional argument ARG to nios2-iss, may
                              be specified repeatedly

Connect to ModelSim Options

  -n, --instance_name=NAME   connect to jtag_uart instance name

Connect to Hardware using UART Options

      --port=PORT            full name of port to connect to (e.g. /dev/com1)
      --baud-rate=RATE       baud rate to connect to UART

Description

Performs terminal I/O with a JTAG UART in a Nios II system.

Usage

nios2-terminal [TERMINAL OPTIONS] [CONNECTION OPTIONS] [TARGET OPTIONS]

Options

Terminal Options

 -V, --version              display version number
  -h, --help                 show this message and exit
  -v, --verbose              show extra information during run (default)
  -q, --quiet                show minimal information
      --write-pid            write process ID to filename specified
  -w, --wait                 wait for a signal before starting
      --flush                empty buffers before displaying output
      --signal-pid           send signal to process ID when ready
  -o, --quit-after=SECS      quit after SECS second(s) (default is never)
      --no-quit-on-ctrl-d    don't quit if Ctrl-D received from target
  -u, --dump=OPTS            dump extra debug information for OPTS
      --gmon                 write gmon.out file if seen from target
      --no-gmon              do not write gmon.out

Connection Options

   -H, --hardware             connect to a hardware target (default)
      --persistent           try to reconnect after an I/O error
      --no-persistent        opposite of persistent

Connect to Hardware Options

  -c, --cable=CABLE          use CABLE JTAG cable (default auto-detect)
  -d, --device=DEVICE        connect to DEVICE device (default auto-detect)
  -i, --instance=INSTANCE    connect to INSTANCE instance (default auto-detect)

Description

This utility checks that the zip file you have chosen is compatible with the Altera Read Only Zip Filing system. It returns 0 if the zip file is compatible, -1 if not.

Usage

validate_zip name_of_zip_file

Description

This tool configures an configurable part. If no explicit SOF file is provided then it will try and work out the correct file to use.

Usage

nios2-configure-sof [-h/--help] [-C/--directory <dir name>]
       [-c/--cable <cable name>] [-d/--device <device index>]
           [ <filename.sof> ]

Options

-h/--help                   Prints this message.

 -C/--directory <dir name>   Change to this directory before running

 -c/--cable <cable name>     Specifies which JTAG cable to use (not needed if
                             you only have one cable).
 -d/--device <device index>  Specifies in which device you want to look for the
                             Nios II CPU (1 = device nearest TDI etc.)

 <filename.sof>              The SOF file you want to download

If you have exactly one cable attached then nios2-configure-sof will use this cable by default. If you have more than one cable attached then you must specify one. Use `jtagconfig` to find out which cables you have available. If a SOF file is specified, then that file is configured into the part. If no file is specified, or if the specified filename does not have a path associated with it then the tool will search for matching SOF files, first in the current directory and then in the directory which contains the PTF file for the project in the current directory.

Description

Allows you configure the JTAG server on the host machine. It can also detect a JTAG chain and set up the download hardware configuration.

Usage

jtagconfig [--enum]
       jtagconfig --add <type> <port> [<name>]
       jtagconfig --remove <cable>
       jtagconfig --getparam <cable> <param>
       jtagconfig --setparam <cable> <param> <value>
       jtagconfig --define <jtagid> <name> <irlength>
       jtagconfig --undefine <jtagid> <name> <irlength>
       jtagconfig --defined
       jtagconfig --addserver <server> <password>
       jtagconfig --enableremote <password>
       jtagconfig --disableremote
       jtagconfig --version
       jtagconfig --help
       jtagconfig --extrahelp

Options

--version | -v    Displays the version of the jtagconfig utility you are using.                                    

--help | -h       Displays the options for the jtagconfig utility.

--extrahelp       Displays this help information.

--enum            Displays the JTAG ID code for the devices in each JTAG chain
                  attached to programming hardware. If the JTAG Server        
                  recognizes a device, it displays the device name. If the    
                  JTAG Server cannot use a device, it marks the device with an
                  exclamation mark (!).                                       

                  The following code is an example of output from the
                  'jtagconfig --enum' command:                       

                  1) ByteBlasterMV on LPT1
                  090010DD   EPXA10       
                  049220DD   EPXA_ARM922  
                  04000101 !              
                  090000DD ! EP20K1000E   
                  04056101 !              
                  010020DD   EPC2         
                  010020DD   EPC2         
                  010020DD   EPC2         

                  In this example, the JTAG Server does not recognize two of
                  the eight devices, and cannot use three devices.  If you need
                  to use one of the unused devices then use the --define option
                  to define unused devices with JTAG IDs.                      

                  You can also use this option by typing the command
                  'jtagconfig' without an argument.                 

--add <hardware>  Specifies the port to which you attached new programming
  <port> [<name>] hardware. For example, 'jtagconfig --add byteblastermv lpt1'
                  specifies that you attached a ByteBlasterMV cable to port   
                  LPT1. You can also use '[<name>]' to add a string that      
                  describes the hardware to the output from the               
                  'jtagconfig --enum' command.                                

                  The JTAG Server automatically detects cables that you attach
                  to a USB port, therefore you do not need to use this command
                  for these cables.                                           

--remove <cable>  Removes the hardware setup that is indicated with the number
                  listed for the hardware in the output of the '--enum'       
                  command. In the example for the '--enum' command, above, the
                  number '1)' is listed for the ByteBlasterMV cable.          
                  Therefore, the command-line 'jtagconfig --remove 1' removes 
                  the hardware setup for the ByteBlasterMV cable.

                  If the hardware specified is attached to a remote JTAG server
                  then the connection to the remote JTAG server will be removed                  instead.

--getparam        Get a hardware specific parameter from the cable specified.
<cable> <param>   The parameters supported vary by cable type, see the
                  documentation for your cable for details.

--setparam        Set a hardware specific parameter on the cable specified.
<cable> <param>   The parameters supported vary by cable type, see the
<value>           documentation for your cable for details.
                  This command can only set numeric parameters (the suffixes
                  k and M are recognised when parsing the value).

--define <jtagid> Tells the JTAG server about the name and IR length of a new
<name> <irlength> device.  This will be stored and used in future enumerations
                  to reduce the number of devices which cannot be used

--undefine        Tells the JTAG server to remove information about the name
<jtagid> <name>   and IR length of a device.

--defined         Displays the JTAG IDs, names and IR lengths of all non-Altera
                  devices known about by the JTAG server.

--addserver       Tells Quartus to connect to the remote JTAG server and make
<servername>      all cables on that server available to local applications.
<password>

                  An IP address or DNS name may be used to specify the server
                  to connect to.  The password given here must match the
                  password used on the remote server.

--enableremote    Tells the JTAG server to allow connections from remote
<password>        machines.  These machines must specify the same password
                  when connecting.

--disableremote   Tells the JTAG server not to accept any more connections
                  from remote machines.  Remote connections currently in use
                  are not terminated.

• Integration with the newlib ANSI C standard library—Provides the familiar C standard library functions
• Device drivers—Provides access to each device in the system
• The HAL API—Provides a consistent, standard interface to HAL services, such as device access, interrupt handling, and alarm facilities
• System initialization—Performs initialization tasks for the processor and the runtime environment before main()
• Device initialization—Instantiates and initializes each device in the system before main() runs

The Layers of a HAL-Based System

For further details about the HAL, refer to the "Developing Programs Using the Hardware Abstraction Layer" and "Developing Device Drivers for the Hardware Abstraction Layer" chapters.

• Character-mode devices—Hardware peripherals that send and/or receive characters serially, such as a UART.
• Timer devices—Hardware peripherals that count clock ticks and can generate periodic interrupt requests.
• File subsystems—A mechanism for accessing files stored in physical device(s). Depending on the internal implementation, the file subsystem driver might access the underlying device(s) directly or use a separate device driver. For example, you can write a flash file subsystem driver that accesses flash using the HAL API for flash memory devices.
• Ethernet devices—Devices that provide access to an Ethernet connection for a networking stack such as the Altera-provided NicheStack^® TCP/IP Stack - Nios II Edition. You need a networking stack to use an ethernet device.
• Direct memory access (DMA) devices—Peripherals that perform bulk data transactions from a data source to a destination. Sources and destinations can be memory or another device, such as an Ethernet connection.
• Flash memory devices—Nonvolatile memory devices that use a special programming protocol to store data.

• Character mode devices
  • UART core
  • JTAG UART core
  • LCD 16207 display controller
• Flash memory devices
  • Common flash interface compliant flash chips
  • Intel FPGA’s erasable programmable configurable serial (EPCS) serial configuration device controller
• File subsystems
  • Intel FPGA host based file system
  • Intel FPGA read-only zip file system
• Timer devices
  • Timer core
• DMA devices
  • DMA controller core
  • Scatter-gather DMA controller core
• Ethernet devices
  • Triple Speed Ethernet MegaCore^® function
  • Standard Microchip Solutions (SMSC) LAN91C111 10/100 Non-PCI Ethernet Single Chip MAC + PHY
• EPCQ soft IP peripheral
  • Upgraded to add support for x4 mode and L devices, giving faster access to the EPCQ device from Nios or other FPGA based masters

The LAN91C111 and Triple Speed Ethernet components require the MicroC/OS-II runtime environment.

For more information, refer to the "Ethernet and the NicheStack TCP/IP Stack - Nios II Edition" chapter.

Inevitably, certain peripherals have hardware-specific features with usage requirements that do not map well to a general-purpose API. The HAL handles hardware-specific requirements by providing the UNIX-style ioctl() function. Because the hardware features depend on the peripheral, the ioctl() options are documented in the description for each peripheral.

Some peripherals provide dedicated accessor functions that are not based on the HAL generic device models. For example, Altera provides a general-purpose parallel I/O (PIO) core for use with the Nios II processor system. The PIO peripheral does not fit in any class of generic device models provided by the HAL, and so it provides a header file and a few dedicated accessor functions only.

For complete details regarding software support for a peripheral, refer to the peripheral’s description.

For more information about Altera-provided peripherals, refer to the Embedded Peripherals IP User Guide.

Every HAL-based Nios II program consists of two Nios II projects.

For more information, refer to the figure above. Your application-specific code is contained in one project (the user application project), and it depends on a separate BSP project (the HAL BSP).

The application project contains all the code you develop. The executable image for your program ultimately results from building both projects.

With the Nios II SBT for Eclipse, the tools create the HAL BSP project when you create your application project. In the Nios II SBT command line flow, you create the BSP using nios2-bsp or a related tool.

The HAL BSP project contains all information needed to interface your program to the hardware. The HAL drivers relevant to your hardware system are incorporated in the BSP project.

The BSP project depends on the hardware system, defined by a SOPC Information File (.sopcinfo). The Nios II SBT can keep your BSP up-to-date with the hardware system. This project dependency structure isolates your program from changes to the underlying hardware, and you can develop and debug code without concern about whether your program matches the target hardware.

You can use the Nios II SBT to update your BSP to match updated hardware. You control whether and when these updates occur.

For more information about how the SBT keeps your BSP up-to-date with your hardware system, refer to “Revising Your BSP” in the "Nios II Software Build Tools" chapter.

In summary, when your program is based on a HAL BSP, you can always keep it synchronized with the target hardware with a few simple SBT commands.

The system.h file describes each peripheral in the system and provides the following details:

• The hardware configuration of the peripheral
• The base address
• Interrupt request (IRQ) information (if any)
• A symbolic name for the peripheral

The Nios II SBT generates the system.h file for HAL BSP projects. The contents of system.h depend on both the hardware configuration and the HAL BSP properties.

For more information about how to control BSP settings, refer to the “HAL BSP Settings” chapter.

Example 6–1. Excerpts from a system.h File Detailing Hardware Configuration Options

/*
* sys_clk_timer configuration
*
*/
#define SYS_CLK_TIMER_NAME "/dev/sys_clk_timer"
#define SYS_CLK_TIMER_TYPE "altera_avalon_timer"
#define SYS_CLK_TIMER_BASE 0x00920800
#define SYS_CLK_TIMER_IRQ 0
#define SYS_CLK_TIMER_ALWAYS_RUN 0
#define SYS_CLK_TIMER_FIXED_PERIOD 0
/*
* jtag_uart configuration
*
*/
#define JTAG_UART_NAME "/dev/jtag_uart"
#define JTAG_UART_TYPE "altera_avalon_jtag_uart"
#define JTAG_UART_BASE 0x00920820
#define JTAG_UART_IRQ 1

The header file alt_types.h defines the HAL type definitions.

The following list contains all of the available UNIX-style functions:

• _exit()
• close()
• fstat()
• getpid()
• gettimeofday()
• ioctl()
• isatty()
• kill()
• lseek()
• open()
• read()
• sbrk()
• settimeofday()
• stat()
• usleep()
• wait()
• write()

The most commonly used functions are those that relate to file I/O.

For more information, refer to the “File System” chapter.

For more information about the use of these functions, refer to the "HAL API Reference" chapter.

For more information, refer to an example in the "Read-Only Zip File System" chapter.

You can access files in a HAL-based file system by using either the C standard library file I/O functions in the newlib C library (for example fopen(), fclose(), and fread()), or using the UNIX-style file I/O provided by the HAL.

The HAL provides the following UNIX-style functions for file manipulation:

• close()
• fstat()
• ioctl()
• isatty()
• lseek()
• open()
• read()
• stat()
• write()

For more information about these functions, refer to the "HAL API Reference" chapter.

The HAL registers a file subsystem as a mount point in the global HAL file system. Attempts to access files below that mount point are directed to the file subsystem. For example, if a read-only zip file subsystem (zipfs) is mounted as /mount/zipfs0, the zipfs file subsystem handles calls to fopen() for /mount/zipfs0/myfile.

There is no concept of a current directory. Software must access all files using absolute paths.

The HAL file infrastructure also allows you to manipulate character mode devices with UNIX-style path names. The HAL registers character mode devices as nodes in the HAL file system. By convention, system.h defines the name of a device node as the prefix /dev/ plus the name assigned to the hardware component at system generation time. For example, a UART peripheral that appears as uart1 in Qsys is named /dev/uart1 in system.h.