Nios II Processor v5.0 Errata: Hardware

• Nios II Processor Core
• Peripherals
• SOPC Builder and Quartus II Software
• Host Platform
• Device
• Development Boards
• Download Cables and Debug Hardware
• Hardware Simulation

Nios II Processor Core

This section lists any issues related to the Nios^® II processor core.

There are no known issues at this time.

Peripherals

This section lists any issues related to the Nios II peripherals included in the Nios II Development Kit.

LAN91C111 component does not monitor the ARDY signal

The LAN91C111 component does not use the ARDY signal and therefore may not properly handle bursts from peripherals such as a direct memory access (DMA) controller.

Workaround: Do not use bursting peripherals such as DMA with the LAN91C111 component.  Please contact Altera^® Applications for potential workarounds.

JTAG UART is unstable after device-wide reset

If the DEV_CLRn pin on the FPGA input has been assigned (in Quartus^® II software) to generate a device-wide reset, and the FPGA is reset while the JTAG UART is active, then the JTAG UART might become unstable.

Workaround: Do not use the DEV_CLRn function on the FPGA. Turn off the Enable Device-Wide Reset (DEV_CLRn) setting in the Quartus II software.

SOPC Builder & Quartus II Software

This section lists issues related to SOPC Builder and Quartus II software support for the Nios II processor.

Reset address in TCM with no other instruction master memory causes false warning

Placing program memory (.text) and data memory (.rodata and .rwdata, etc) in a dual port memory in which only instruction masters are connected to one port and only data masters of the same CPU are connected to the other port is not supported. A typical case where this might be done would be a dual port memory with one port connected to a tightly coupled memory (TCM) instruction master and the other port connected to a TCM data master. This configuration is not supported.

Workaround: Do not place program memory (.text) and data memory (.rodata and .rwdata, etc.) in a dual port memory in which only instruction masters are connected to one port and only data masters are connected.

Quartus II project settings lost after SOPC Builder launch

If SOPC Builder is opened by double-clicking the symbol, subsequent Quartus II project setting changes made while SOPC Builder is open are lost if a regeneration in SOPC Builder is performed immediately after making the changes. When SOPC Builder exits, the project settings are updated, overwriting any changes made while SOPC Builder was open.

Workaround: Either open SOPC Builder from the tools menu always, or simply make Quartus II project setting changes after modifications within SOPC Builder are complete.

Invalid pin assignments in Quartus II for bus signals with multiple I/O types

Bused I/O pins become split into smaller groups when the bus has various types (input, output, and bi-directional). Due to the splitting of the bus, MAX+PLUS^® II naming conventions become used. This can cause pin assignments to be ignored even if they appear to be assigned if you use schematic entry in the top level. For example: If outputbus[3..0] is an output pin, and outputbus[4] is a bidirectional pin. Quartus II software will view these as being outputbus0, outputbus1, .... outputbus4, etc.

Workaround: Do not use the same naming convention for pins of different types (in the example renaming outputbus[3..0] to something else would not conflict with bit 4 and visa-versa).

Host Platform

This section lists any issues related specifically to the host platform.

Debugging with the Nios II ISS target can cause a process leak on Linux

If you try to interrupt or terminate a running program on the Nios II instruction-set simulator (ISS) target during a debug session, you may see an error message: Interrupt Failed or Terminate Failed. This means that the nios2-iss process has failed to terminate and you will have to return to the command line in order to kill the process. Please note that although the launch may be removed successfully, the nios2-iss process still remains alive.

Restoring the factory-contents of flash on a Nios development board may fail on Linux

Typing "./restore_my_flash" to restore the factory-contents of flash on a Nios development board may fail on Linux platforms.

Workaround: Start a Nios II software development kit (SDK) shell by opening a terminal window, switching to <Nios II Installation Directory>, and then typing "./sdk_shell". Once the SDK shell is open, change directories to the factory recovery directory for your Nios development board and type "perl restore_my_flash.pl" to restore flash. This issue will be fixed in a future Nios II release.

The Quartus II stand-alone programmer is not supported on Linux

On Linux, the Nios II Integrated Development Environment (IDE) cannot launch the Quartus II stand-alone programmer. As a result, in the Nios II IDE the Tools > Quartus II Programmer command has no effect, and the IDE does not automatically launch the programmer when you attempt to download software to a board that does not match the expected hardware image.

Workaround: Launch the Quartus II software to access the Quartus II stand-alone programmer.

Frisk antivirus software causes SOPC Builder and Nios II SDK to be unresponsive

The SOPC Builder and Nios II SDK shell may become unresponsive if run while the Frisk antivirus software is running.

Workaround: Turn off the Dynamic Virus Checking feature of the Frisk software before running SOPC Builder or the Nios II SDK shell.

Device

This section lists any device-related issues.

Stratix II EP2S60 ES devices cannot use MRAM byte enables

Early shipments of the Nios development board, Stratix^® II Edition include an EP2S60 engineering sample (ES) device. Stratix II EP2S60 ES devices have a silicon problem that prevents the use of byte enables on MRAM blocks. Refer to the Stratix II FPGA Family Errata Sheet (PDF) for details.

Development Boards

This section lists any issues related to Altera development boards.

Nios II Development Board, Cyclone II Edition SSRAM data bus bytes are swapped

The top two bytes of the SSRAM data are reversed on the Nios II Development Board, Cyclone^® II Edition.  The design examples account for this by swapping the byte enables 2 and 3 (C and D on the board schematic) in the top level schematic.

Workaround: Ensure that you have swapped the SSRAM byte enables as illustrated in the example designs when creating new designs.  Refer to the Nios Development Board, Cyclone II Edition Reference Manual for more information.

Intermittent failures while accessing Compact Flash card

Nios II processor version 5.0 includes a Compact Flash controller peripheral suitable for interfacing to Compact Flash cards in True IDE mode on Nios development boards. In order for True IDE mode to operate, Compact Flash cards require that the "ATASEL_N" input be driven to ground during power-up.

The Compact Flash controller peripheral includes a configurable power register used to power-cycle Compact Flash cards in Nios II software through a MOSFET on the Nios development boards. However, in certain development boards, power to the Compact Flash card will not be turned off completely during this power-cycle operation. Because of this, the "ATASEL_N" pin may not be sampled during the power-cycle operation after FPGA configuration when this pin is driven to ground. Instead, "ATASEL_N" may be sampled by the Compact Flash card when power is first applied to the development board, when I/O are not yet driven by the FPGA (before FPGA configuration).

Workaround:  If you encounter errors with Compact Flash when using the Nios development boards, please try one of the following workarounds:

• Try a different Compact Flash card -- Certain cards are more susceptible to the power-cycling issue than others.

• Modify the Nios development board -- This is recommended for users who are familiar and comfortable with board-level modifications. Disconnect pin 9 (ATASEL_N) on the Compact Flash socket on your Nios Development Board and tie this pin to ground. Note that the Compact Flash socket uses a staggered numbering on the pins (starting from pin 1: 1, 26, 2, 27, ...); please refer to the Compact Flash Association specification for right-angle surface-mount connectors for exact specifications on this connector. Caution: This will permanently enable True-IDE mode operation.

Compact Flash card and LCD screen do not work concurrently

If there is a Compact Flash card inserted in the development board, the LCD and other devices connected to the PROTO1 header might not work.

Workaround: Remove the Compact Flash card to ensure proper operation of the PROTO1 header, or vice versa.

Networking Examples

If you are running a networking example design and you are asked for a 9-digit number after the letters 'ASJ', and your Nios II development board does not have a sticker with a 9-digit number after the letters 'ASJ', please enter a unique 9-digit number when prompted. Ensure that this number is unique to each Nios board connected to your network to avoid network address conflicts.

Download Cables and Debug Hardware

This section lists any issues related to download cables and other debug hardware.

Communication errors during run/debug sessions using older download cables

Debugging with the following Altera download cables might fail, due to electrical noise-related JTAG communication failures: the USB-Blaster^TM Rev A, ByteBlaster™, ByteBlasterMV™, ByteBlaster II, and MasterBlaster™ cables.

Currently, the only fully supported cable for downloading, debugging, or communicating with Nios II systems is the USB-Blaster Rev B or later. Revision B cables are clearly labeled as Revision B (Revision A cables have no revision label).

Workaround: Use a USB-Blaster Rev B cable. Older cables can be used, but they might encounter JTAG communication failures.

Hardware Simulation

This section lists issues related to simulating Nios II processor systems on a register transfer level (RTL) simulator, such as the ModelSim^® simulator.

Simulation failure if reset address is set to EPCS

Running ModelSim RTL simulation of a Nios II system will fail if the reset address of the Nios II processor is set to an EPCS Serial Flash Controller.

Workaround: To simulate your system, temporarily set the Reset Address of the Nios II CPU to the memory that your application code will reside (for example, SDRAM), then re-generate the system in SOPC Builder and run RTL simulation again. Before booting the Nios II CPU from EPCS flash on your target board, change the Nios II Reset Address back to the EPCS Controller peripheral and re-generate the system in SOPC Builder and re-compile in the Quartus II software to produce an updated FPGA configuration file in which Nios II will boot from EPCS flash.

Uninitialized BSS variables in simulation

If your program reads the value of an uninitialized BSS variable during HDL simulation when the HAL system library has been compiled with the 'Modelsim only, no hardware support' property enabled in Nios II IDE, a warning will be produced about unfiltered data being ‘x’. This occurs because, when this property is enabled, the code that clears the BSS memory region is omitted to speed up HDL simulation so this memory region is uninitialized. The BSS region contains global and static local variables that are not initialized by the application so they default to a value of zero. When the Nios II CPU reads uninitialized variables, it displays a warning and converts any of the bits of the uninitialized data to zero which correctly mimics the effect of the missing BSS clearing code. The HAL code that executes before and after main() may use BSS variables so these warnings may be generated even if your application doesn’t use the BSS.

"No Printer Selected" error when attempting ModelSim simulation, if simulation is not enabled in SOPC Builder

If you did not enable the simulation option in SOPC Builder when generating the system, and attempt Run As > Nios II ModelSim in the Nios II IDE, you will get an error stating that you there are no simulation files. This might also generate a benign error stating "No Printer Selected" if your host system has no printers enabled.

Workaround: To successfully simulate your design, enable the simulation option in SOPC Builder, regenerate, and perform the Run As...Nios II ModelSim in the IDE again.

ModelSim fails to load large memory models

ModelSim might fail to load simulation models for memory arrays larger than 128 Mbytes, halfwords or words in size. If the sum of the following parameters is greater than 27, ModelSim will fail to load:

• address_bits (i.e. 14)
• column bits (i.e. 11)
• log2(number of banks) (number of banks is usually 4, so this term is usually 2)
• log2(chipselects) (number of chipselects is usually 1, so this term is usually 0)

Workaround: Simulate using a smaller SDRAM than the SDRAM implemented in hardware. This is possible if the entire memory space doesn’t need to be simulated.