- 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 cores.
[Updated] License error when using USB GuardYou may get the following error message during generation of your Nios II system in SOPC Builder if you are using a USB Guard to license the Nios II embedded processor. As a result, a time-limited programming file will be generated.
"Error: newer version of software required to read license key version: 3
# 2005.04.12 07:32:10 (*) Encrypted license not found."Workaround: Replace the eperl.exe file in your <Nios II install dir>\components\altera_nios2 directory with this updated eperl.exe. Regenerate your system and a non-time-limited core will be generated.
Peripherals
This section lists any issues related to the Nios II peripherals included in the Nios II development kit.
[Updated] JTAG_UARTs with names other than "jtag_uart" may not work with Nios II IDE software templates.JTAG UART is unstable after device-wide resetSome of the Nios II IDE software templates are hard-coded to use a JTAG UART named jtag_uart for STDIN, STDOUT, and STDERR. Changing the name of the JTAG UART, or instantiating a JTAG UART with a different name may cause certain software templates not to automatically choose the correct one for stdio.
Workaround: Either name your JTAG UART "jtag_uart" exactly, or manually set the STDIN, STDOUT, and STDERR devices to your JTAG UART in the Nios II IDE System Library Properties screen.
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
[Updated] SOPC Builder may hang if multiple versions of Nios II are installed on the host system.[Updated] On-chip memories in SOPC Builder systems targeting HardCopy may cause the Quartus II fitter to failWhen multiple versions of the Nios II processor are installed on the system, SOPC Builder can hang when starting the application.
Workaround: Ensure only one version of the Nios II processor is installed on the system. If multiple versions are installed, uninstalling one of them will resolve the issue.
Reset address in TCM with no other instruction master memory causes false warningOn-chip memories can be initialized during the Quartus II compile for FPGAs, but not for HardCopy® devices. The Quartus II fitter may fail if an on-chip memory specifies an initialization file, and the design is being compiled for a HardCopy device.
Workaround: Check the "HardCopy Compatible" checkbox next to the Board Target near the top of the SOPC Builder System Contents screen.
Quartus II project settings lost after SOPC Builder launchPlacing 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 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.
Invalid pin assignments in Quartus II for bus signals with multiple I/O typesIf 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 always open SOPC Builder from the tools menu, or simply make Quartus II project setting changes after the modification within SOPC Builder is complete.
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.
[Updated] F1 Help in the Nios II IDE does not function on LinuxDebugging with the Nios II ISS target can cause a process leak on LinuxThere is currently no workaround. This will be addressed in a future version.
Linux: Restoring the factory-contents of flash on a Nios development board may fail.If you try to interrupt or terminate a running program on the Nios II 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.
Workaround: Return to the command line and kill the process. Please note that although the launch may be removed successfully, the nios2-iss process still remains alive.
Linux: The Quartus II stand-alone programmer is not supported on LinuxTyping "./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 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.
Frisk antivirus software causes SOPC Builder and Nios II SDK to be unresponsiveOn Linux, the Nios II 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 Quartus II software to access the Quartus II Programmer.
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 enablesEarly 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 MRAM blocks. Refer to the Stratix II FPGA Family Errata Sheet 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 swappedIntermittent failures while accessing CompactFlash cardThe 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 II Development Board, Cyclone II Edition Reference Manual for more information.
CompactFlash card and LCD screen don't work concurrentlyThe Nios II processor version 5.0 and higher 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.
Networking ExamplesIf there is a CompactFlash card inserted in the development board, the LCD and other devices connected to the PROTO1 header might not work.
Workaround: Remove the CompactFlash card to ensure proper operation of the PROTO1 header, or vice versa.
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 cablesDebugging 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 an RTL simulator, such as the ModelSim® simulator.
Simulation failure if reset address is set to EPCSUninitialized BSS variables in simulationRunning 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 Quartus to produce an updated FPGA configuration file in which the Nios II CPU will boot from EPCS flash.
"No printer selected" error when attempting ModelSim simulation if simulation is not enabled in SOPC BuilderIf 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.
ModelSim fails to load large memory modelsIf 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.
The ModelSim tool might fail to load simulation models for memory arrays larger than 128M bytes, 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 (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.
