5.1 Errata: Hardware

Nios II Processor Core

This section lists any issues related to the Nios II processor cores.

Data cache issue—Updated January 4, 2006

The Nios II data cache, with a line size of 16 or 32 bytes/line, causes memory corruption when the following actions occur in sequence:

  1. The processor issues a store instruction that maps to any word except the last on a data cache line.
  2. The processor issues a second store instruction that maps to the last word on the same cache line that was used by the first instruction.

The following example illustrates this issue:

  • System: Nios II/f core with data cache size of 1 Kbyte @ 32 bytes/line (8 words per line)
  • Instruction 1: Store to address [8]
  • Instruction 2: Store to address [1024+28]

The first store instruction maps to the third word on the first data cache line. The second store instruction maps to the last word on the first data cache line. (The offset of 1024 bytes causes a cache access that wraps around to the first cache line.) Since the second store instruction caused a miss (tag bits are different), the line is written back to main memory. However, the write back location (corresponding to address [1024+28]), is not updated prior to write back and memory is written with the stale value that was present in the cache RAM before the first store instruction was executed. The net result is that the second store is corrupted.

Solution: Apply the Nios II 5.1 Patch 2 for PC (.zip) or Nios II 5.1 Patch 2 for Linux (.tar) to correct the problem.

The alternative to using the patch is to reduce the data cache line size down to 4 bytes/line or remove the data cache from the design.


This section lists any issues related to the embedded peripherals included with the Quartus II software version 5.1, which might impact Nios II users.

PLL Component's PFD enable signal is not accessible via the Avalon control register

On the SOPC Builder phase-locked loop (PLL) component, you cannot access the pfdena signal through the Avalon® control register. If you enable the pfdena signal on the altpll block, the PLL component configuration GUI allows you to select that you want to access the pfdena signal via the phase frequency detector (PFD) enable bit in the control register. However, the hardware does not support this mode of operation. Software attempting to access the PFD enable bit will not function correctly.

Workaround: You can export the pfdena signal to the top level of the system module, or you can disable the pfdena signal on the altpll. The hardware supports this feature in version 6.0 of the Quartus II software.

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 Quartus II software.

SOPC Builder and Quartus II Software

Reads to tristate peripherals may lock system—Updated January 4, 2006

In version 5.1 of the Quartus II SOPC Builder software, read accesses to a tristate bridge that connects to off-chip devices, including SDRAM, may lock the system indefinitely. For example, if SDRAM memory and flash memory share the same tristate bridge, the system might hang after an initial access to one of the memories. This issue was not present in either version 5.0 or 5.0 SP1 and will be fixed prior to version 5.1 SP1.

Solution: The following patches (for Linux and Windows) place an updated e_ptf_slave_arbitration_module.pm into the $QUARTUS_ROOTDIR/sopc_builder/bin/europa directory:

Patch for Linux (.tar)

Patch for Windows (.exe)

Design failures after editing version 5.1 SOPC Builder system—Updated December 5, 2005

Due to a known issue in the Quartus II software version 5.1, designs that use the following encrypted intellectual property (IP) cores may fail to compile in the Quartus II software or fail functionally in simulation or hardware.

  • Nios II
  • POS-PHY Level 4
  • RapidIO® standard
  • SerialLite II
  • SONET/SDH Compiler

The issue is caused by a failure to detect changes to encrypted intellectual property (IP) core source files generated by SOPC Builder or IP Toolbench. The Quartus II software versions 5.0 and earlier do not have this issue.

Workaround: Apply the Quartus II Critical Issue Patch to correct the problem.

Cannot connect Nios II tightly-coupled instruction and data masters to the same dual-port memory

SOPC Builder does not generate an error if you connect Nios II tightly-coupled instruction and data masters to both ports on a dual-port on-chip memory. However, this configuration is not supported in hardware.

Workaround: Do not connect Nios II tightly-coupled masters to both ports of a dual-port memory.

Host Platform

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

Linux: F1 Help in the Nios II IDE does not function on Linux

Workaround: There is currently no workaround. This issue will be addressed in a future version.

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

If you try to interrupt or terminate a debug session targeting the Nios II instruction set simulator (ISS), you might see an "Interrupt Failed" or "Terminate Failed" error message. This means that the nios2-iss process failed to terminate. The debug session appears to have terminated in the IDE, but the nios2-iss process still remains alive.

Workaround: Open a command shell and kill the nios2-iss process.

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

There is no Quartus II stand-alone programmer for Linux. As a result, in the Nios II IDE the Quartus II Programmer command on the Tools menu has no effect. 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 Programmer.

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

The SOPC Builder and Nios II Software Development Kit (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.


This section lists any device-related issues.

Stratix II EP2S60 ES devices cannot use M-RAM byte enables

Early shipments of the Nios II Development Kit, 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 M-RAM blocks.

Workaround: There is no workaround. 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 Cyclone II Development Board 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 Nios II hardware design examples account for this reversal by swapping the byte enables 2 and 3 lines (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 II Development Board, Cyclone II Edition Reference Manual (PDF) for more information.

Intermittent failures while accessing CompactFlash card

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

The CompactFlash controller peripheral includes a configurable power register used to power-cycle CompactFlash cards in Nios II software through a MOSFET on the Nios development boards. However, in certain development boards, power to the CompactFlash card will not turn off completely during this power cycle operation. Because of this, the CompactFlash might not sample the ATASEL_N pin during the power-cycle operation after FPGA configuration when this pin is driven to ground. Instead, the CompactFlash card might sample the ATASEL_N pin 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 CompactFlash when using the Nios development boards, try one of the following:

  • Use a different CompactFlash 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 CompactFlash socket on your Nios development board and tie this pin to ground. Note that the CompactFlash socket uses a staggered numbering on the pins (starting from pin 1: 1, 26, 2, 27, ...); refer to the CompactFlash Association specification for right-angle surface-mount connectors for exact specifications on this connector. This modification will permanently enable True-IDE mode operation.

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: USB-Blaster™ 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 cable 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.

No activity in VHDL simulation—Updated December 19, 2005

When simulating the VHDL reference designs that ship with the Nios II development kit the input clock to the system will drive an 'X' instead of logical values. This causes simulations to fail as the processor remains in a reset state. Verilog designs are not affected by this problem.

The processor clock is driven via a phased locked loop (PLL). The corresponding <PLL module name>.vhd file instantiates a lower level module called altpll<PLL module name>. The setup_sim.do script generated by the SOPC Builder tool incorrectly compiles the <PLL module name>.vhd file before altpll<PLL module name>.vhd.

Workaround: To correct this problem modify the setup_sim.do script to compile altpll<PLL module name>.vhd before the <PLL module name>.vhd file.

The PLL also requires a simulator resolution of picoseconds whereas the setup_sim.do script uses a resolution of nanoseconds. Modify the setup_sim.do script to use a resolution of picoseconds by changing the following lines:

if { [ vsimAuth ] == "ALTERA" } {
alias _vsim {vsim +nowarnTFMPC -L lpm -L altera_mf -L sgate test_bench } } else {
alias _vsim {vsim +nowarnTFMPC test_bench } }

to read:

if { [ vsimAuth ] == "ALTERA" } {
alias _vsim {vsim -t ps +nowarnTFMPC -L lpm -L altera_mf -L sgate test_bench } } else {
alias _vsim {vsim -t ps +nowarnTFMPC test_bench } }

After saving the setup_sim.do script rerun the script in ModelSim by typing:

do setup_sim.do

You can then rerun the simulation and the pll will correctly drive the input clock port.

Note that SOPC Builder generation overwrites the setup_sim.do file. Therefore, you should make a backup copy of the modified setup_sim.do file.

Simulation failure if reset address is set to EPCS

Running ModelSim RTL simulation of a Nios II system fails 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 Quartus to produce an updated FPGA configuration file in which the Nios II CPU will boot from EPCS flash.

Uninitialized BSS variables in simulation

If the 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’.

Workaround: There is no workaround. This issue occurs because once 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 might 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

The ModelSim tool 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, the ModelSim tool will fail to load:

  • address_bits (14)
  • column bits (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.