New Qsys Issues

From Altera Wiki
Jump to: navigation, search
4 / 5 (1 vote cast)

Contents

Overview

 

The purpose of this page is to keep an active list of Qsys issues and workarounds over the first few releases of the tool in the Quartus II software. 

Before adding to this page please review the following documents to learn more about Qsys or the known issues list:

 

If you find an issue, please file a service request at mysupport so that it can be tracked and addressed by Altera:  http://www.altera.com/mysupport

Formatting

If you find a new issue please add it to the list below by editing this page so that others can benefit from it as well.  So that the formatting will be consistent, please use the Issue:Workaround format and provide short descriptive titles using the "Heading 3" format under the appropriate New Issues section. 

 

New Issues


Qsys Editor (UI) Issues

Issue: Qsys doen't remember the user-entered IP search path (Tools -> Options ). Adding the user_components.ipx as described on page 5-13 (Quartus II Handbook Version 12.0) doesn't work either. This usually occurs when launching Qsys outside a Quartus II project. The path used (in 13.0 sp1) appears to be based on the path to the QSYS file that is currently open, and not on the user's path configuration. I also observe that paths in project specific xxx.ipx files are used when qsys-edit is first run, but they are later forgotten when QSYS opens a source file (13.0 sp1).

  Workaround: add a <Path path=... /> entry into the main <$QUARTUS_INSTALLDIR>/sopc_builder/bin/root_components.ipx file.   Fixed in Quartus II 12.1 (The problem is observed to remain in 13.0 sp1)


Issue: Qsys Component Editor can't handle SystemVerilog packages in the top level file. Use of packages ("import mypackage::*;") causes the Component Editor to fail to find any modules. The error message is:

Error: No modules found when analyzing null.

  Workaround: 1) Make a top level file/wrapper which does not use packages.  2) Manually create the _hw.tcl file.

Issue: Qsys uses inordenant amount of CPU in a java process under 13.1.4 if you edit more than about 3-4 complex Qsys source files one after another without restarting Qsys. I use Linux, but my colleague notices this problem also on Windows.   Workaround: Restart Qsys frequently.

Issue: Qsys throws some graphic related exceptions under 15.1, and for example the address map editor fails to work, and or the editor becomes painfully (mind numbingly) slow.

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at com.altera.sopceditor.tools.addressmap.AddressMapModel.updateRows(AddressMapModel.java:554)
	at com.altera.sopceditor.tools.addressmap.AddressMapModel.rebuildModel(AddressMapModel.java:412)
	at com.altera.sopceditor.tools.addressmap.AddressMapModel$1.run(AddressMapModel.java:813)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$400(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.WaitDispatchSupport$2.run(Unknown Source)
	at java.awt.WaitDispatchSupport$4.run(Unknown Source)
	at java.awt.WaitDispatchSupport$4.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.awt.WaitDispatchSupport.enter(Unknown Source)
	at java.awt.Dialog.show(Unknown Source)
	at java.awt.Component.show(Unknown Source)
	at java.awt.Component.setVisible(Unknown Source)
	at java.awt.Window.setVisible(Unknown Source)
	at java.awt.Dialog.setVisible(Unknown Source)
	at com.altera.ui.app.base.EditorTaskRunner$15.run(EditorTaskRunner.java:591)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$400(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

Workaround: This seems to happen only in a particular design with a nios2 processor in it. I can workaround the problem by using the address column in the main Qsys edit window to modify the base addresses of blocks.

Issue: The 15.1 QSys crashed when saving my file, and I was left with an empty dot qsys file, and so all of my work was lost since I had not yet entered the source file into source code control. This happened immediately after I updated a hw.tcl file to remove an conduit interface, updated the system in qsys, and then attempted to save the qsys system that was including the hw.tcl file as a component.

/boards/Bittware/s43x/atlantis/fmc_116$ Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at com.altera.sopceditor.tools.addressmap.AddressMapModel.updateRows(AddressMapModel.java:554)
	at com.altera.sopceditor.tools.addressmap.AddressMapModel.rebuildModel(AddressMapModel.java:412)
	at com.altera.sopceditor.tools.addressmap.AddressMapModel$1.run(AddressMapModel.java:813)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$400(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.WaitDispatchSupport$2.run(Unknown Source)
	at java.awt.WaitDispatchSupport$4.run(Unknown Source)
	at java.awt.WaitDispatchSupport$4.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.awt.WaitDispatchSupport.enter(Unknown Source)
	at java.awt.Dialog.show(Unknown Source)
	at java.awt.Component.show(Unknown Source)
	at java.awt.Component.setVisible(Unknown Source)
	at java.awt.Window.setVisible(Unknown Source)
	at java.awt.Dialog.setVisible(Unknown Source)
	at com.altera.ui.app.base.EditorTaskRunner$15.run(EditorTaskRunner.java:591)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$400(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00002b7ebe54a835, pid=51343, tid=47823433430784
#
# JRE version: Java(TM) SE Runtime Environment (8.0_05-b13) (build 1.8.0_05-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.5-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x881835]  ObjArrayKlass::oop_oop_iterate_nv(oopDesc*, FastScanClosure*)+0xc5
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# .../hs_err_pid51343.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#
Aborted (core dumped)

Workaround: Save to source code control more frequently, or don’t use proprietary source file formats for serious development work.

Qsys Schematic Issues

Symbol Issues

Issue:  No distinction between inputs and outputs - all signals for a given interface appear on one side. Unless the symbol file is opened (where inputs are represented as light blue crosses, while outputs are represented as purple crosses), one cannot make the distinction between signal types.

 Workaround:  None. For Qsys-generated symbols, the left-input right-output convention appliesy input/output interface, not by individual signal direction.


Other issues related to Block Symbol File (.bsf) symbols and lines were fixed beginning with the Quartus II software version 11.1.


Qsys Interconnect and Avalon Interface Issues

Native Addressing

Issue:  Qsys does not support native addressing.  Qsys will treat all natively address Avalon-MM slave interfaces as dynamically addressed 32-bit interfaces.

Slaves that use native addressing have no byte enables.  Slaves that use dynamic addressing have byte enables.  In Qsys there is only dynamic addressing so any native slave gets treated as a 32-bit slave port and the accesses behave as if there were byte enables present in the slave. So in the case that a slave port was native and 16-bit and Nios II performs a 32-bit access you'll end up with two accesses regardless if the slave used native addressing or not.

  Workaround:  Update any of your own natively addressed custom components to use dynamic addressing and include byte enables for the interface.

Merlin Address Routers for Custom peripherals

Issue:  When generating the system, Merlin address routers are generated ignoring the ExplicitAddressSpan Avalon property. This causes channels to be greater than the complete address space in some cases; for instance, for a system that uses 29 bits of address space (512 MBs), with explicitly using only 16 MBs, Merlin address routers are generated with full 29 bits of address space per channel. Since the complete address space defaults to the size of the address space of the biggest addressable peripheral, this later causes errors in compilation (Verilog errors containing "...part-select direction is opposite from prefix index direction...") and also address space is overlapped with other peripherals with smaller address spaces.

  Workaround:  Manually edit nios_addr_router.sv files (there will be more of them; they are located under \{nios_name}\synthesis\submodules\ directory in your project directory) and manually set the values of the PADx variables to the desired address space size (ExplicitAddressSpanValue = 2^PADxValue). Do not change the value of the complete address space (RG variable), as this might introduce more problems.

Clock sources

Issue: Clocks generated in a subsystem can't be both exported and internally connected.  Master interfaces associated with such clocks will cause problems when hierarchical systems are assembled.  Exporting then re-importing these clocks will infer unnecessary clock-domain-crossing logic and latency.

  Workaround: Anything that generates a global clock, e.g. an SDRAM controller or a PLL, should be instantiated in your top level system. Alternatively, consider using a clock bridge and exporting one side of the bridge.

Issue: Qsys Clock source component interface documentation is ambiguous. The interconnect clock source documentation indicates that Reset synchronous edges might be none, both, or deassert. However the documentation doesn’t indicate if said synchronization is with respect to clock inputs to the block or clock outputs from the block. The user is left guessing about what these options cause to occur, and one of three possible scenarios. Perhaps synchronization must be guaranteed by user circuitry prior to the block inputs, is internally provided by the clock source block, or somehow magically is inserted by the QSYS compiler after the unsynchronized block outputs within the QSYS fabric. I suspect that most users assume that this synchronization is provided by the block or the QSYS fabric (the 2nd two scenarios), but after reading the Avalon interface specification I start to understand that the user must provide any synchronization specified in the clock input block externally to, and before any inputs to the clock source block (the 1st scenario).

Interrupts

Issue: When a tristate device has an interrupt, the BSP builder does not assign the interrupt correctly in system.h: it appears as -1.  The QSYS output is actually correct as can be seen in the generated <designname>.sopcinfo.  This issue has been assigned Altera internal SPR# 373680.

   Workaround: Manually assign the interrupt in system.h after BSP generation in Nios II SBT.

Issue: When an interrupt is exported from a QSYS subsystem through an IRQ Bridge, the BSP builder does not assign the interrupt correctly in system.h: it appears instead as -1.

   Workaround: The problem can be avoided by not using the IRQ Bridge component.

Issue: When an interrupt is exported from a 15.0 QSYS subsystem through an Merlin IRQ ClockCrosser, the BSP builder does not assign the interrupt correctly in system.h: it appears instead as -1.

   Workaround: The problem can be avoided by not using the Merlin IRQ ClockCrosser component.

Avalon-MM address space limit

Issue: The Avalon-MM bus specification is limited to 32-bit addressing. Attempting to generate a DDR3 memory controller with >4GB DIMM will fail. Qsys implementation of AXI interface is also limited to 32-bit addressing.

  Workaround: None yet known.

SystemVerilog Interface support missing

Issue: Qsys does not support SystemVerilog interfaces. It is not possible to define a *_hw.tcl file for components that use interfaces.

  Workaround: Use plain old ugly explicit ports like we did in the 90s.

Component (IP Core) Issues in Qsys 

Unregistered Tri-state Inputs

Issue:  Qsys does not support un-registered tri-state input signals

  Workaround:  Qsys automatically adds an input register to the return data path and compensates for this when upgrading designs that previously used unregistered tri-state inputs.

Component Editor Missing 'clken' definition for MM Slave 

Issue: When building a Slave port to a Memory to connect as a Tightly Connected Data Memory, Qsys warns that a clock enable should be connected. However on the Component Editor Sigals Tab you can not select a 'clken' value for a MM Slave port. 

 Workaround: Manually edit the _hw.tcl file: e.g. add_interface_port ObjectMemory ClkEnOM clken Input 1  

Component Editor Missing 'begintransfer' definition for MM Master

Issue: Qsys Component Editor doesn't present 'begintransfer' choice in Interface Tab

Workaround : assign e.g. 'flush' role to signalput and manually alter the *_hw.tcl file.


Java Error

Issue: Upon opening a Qsys file, the following error is given.

java.lang.StackOverError
at com.altera.utilities.AltString.aintBlank(AltString.java:989)
...

  Cause: A component in the same directory may have the same name (set_module_property NAME example in a CDF tcl file component_hw.tcl) as the Qsys file (example.qsys).

  Workaround:  Don't use the same Qsys design file name as that used by a component in the same directory.


  Issue: Upon opening a Qsys file, the following error is given.

Error: An unexpected error occurred during Open System: java.lang.NullPointerException
Debug: java.lang.NullPointerException
at com.altera.sopcmodel.avalon.AvalonValidator.valida teTightlyCoupledPoints(AvalonValidator.java:422)
at com.altera.sopcmodel.avalon.AvalonValidator.valida te(AvalonValidator.java:62)
at com.altera.sopcmodel.ensemble.EnsembleAddressValid ation.connectionClassValidations(EnsembleAddressVa lidation.java:216)
at com.altera.sopcmodel.ensemble.Ensemble.validateSel f(Ensemble.java:1272)
at com.altera.sopcmodel.beanelement.BeanElement.valid ateSelf(BeanElement.java:391)
at com.altera.sopcmodel.beanelement.BeanElement.valid ate(BeanElement.java:362)
at com.altera.sopcdocument.ReadDocument.read(ReadDocu ment.java:234)
at com.altera.sopcfactories.QsysFactory$1.getObject(Q sysFactory.java:119)
at com.altera.sopcmodel.util.CatalogCard.getObject(Ca talogCard.java:483)
at com.altera.sopcmodel.util.CatalogCard$1.getObject( CatalogCard.java:132)
at com.altera.sopcmodel.util.CatalogCard.getObject(Ca talogCard.java:483)
at com.altera.sopcmodel.util.CatalogCard$1.getObject( CatalogCard.java:132)
at com.altera.sopcmodel.util.CatalogCard.getObject(Ca talogCard.java:483)
at com.altera.sopcplatform.librarian.LibrarianUtils.r eadEnsemble(LibrarianUtils.java:449)
at com.altera.sopceditor.util.EnsembleIO.loadEnsemble (EnsembleIO.java:163)
at com.altera.sopceditor.tools.saveandload.LoadEnsemb leTask.run(LoadEnsembleTask.java:199)
at com.altera.ui.app.base.EditorTaskRunner$12.run(Edi torTaskRunner.java:461)
at com.altera.ui.app.base.ThreadRunner$1.run(ThreadRu nner.java:65)
at java.lang.Thread.run(Unknown Source)

  Cause: I removed an on-chip ram from a subsystem without first removing the nios2 tightly coupled data link to it in the top level system. Apparently QSYS isnt robust in such situations.

  Workaround:

  • I noticed that the Java crash had something to do with validation of nios2 tightly coupled data and instruction masters when QSYS loads a design file into memory, and I also recalled that the last change I made in QSYS was related to moving the SGDMA descriptor ram between the top level system and the network subsystem (because I was unhappy with how the base address was being maintained in two places - both at the top level and at the subsystem level). I decided to try adding the on-chip SGDMA descriptor RAM back into the network subsystem to work around the QSYS crash but I couldn't remember any-longer the name of the on-chip ram master that was used in the export. Finally, after looking in the raw .qsys file with a text editor I determined that the exact name of the export of the ram master, specified in the link in the top level subsystem, was "descr_ram_slave". After properly amending the export name in the network subsytem (using QSYS - I did not modifiy any QSYS files outside of QSYS) then I could open my top level design again in QSYS.
  • See also http://alteraforum.org/forum/showthread.php?t=36542
  • Support is indicating that this issue is fixed in QSYS version 12.1

Tri-state conduits and VHDL component

Issue: If you use a tri-state conduit, eg to a external Flash memory then get the VHDL component declaration from the Qsys "HDL Example" tab, it declares the chip enable, write enable and output enable signals as std_logic_vector(0..0).  These DO NOT connect to the CPU entity declared in the verilog file.

  Workaround: Change the component declaration to just use std_logic for these signals, then everything hooks up ok.

See http://www.alteraforum.com/forum/showthread.php?t=29684 for more details.

Wrong VHDL example in Qsys for different blocks

(Version: Quartus 11sp1)

Qsys is generating a faulty VHDL example. All lines like the following:

bus_ssram_tcm_write_n_out  : inout std_logic_vector(0 downto 0)  := (others => 'X'); -- ssram_tcm_write_n_out 

Should be replaced by:

bus_ssram_tcm_write_n_out  : inout std_logic  := 'X'; -- ssram_tcm_write_n_out 

Even if you use std_logic_vector(0 downto 0) as your top-level I/O's, there can be compilation errors, and worse some lines may be allays high / low or tristate. If a line is false connected, there are warnings (which are hard to find between the others) and you will see the problem in the RTL-Viewer.

This workaround is solving:

New Qsys Issues#Tri-state_conduits_and_VHDL_component

Qsys and tristate bridge

DDR2 SDRAM Controller with ALTMEMPHY Synthesis error

Setting xxxx_hw.tcl EDITABLE parameter to FALSE does not prevent editing xxxx_hw.tcl with the component editor

Issue: If you edit the xxxx_hw.tcl with a text editor and make many changes you would like to prevent a naieve person from opening the the xxxx_hw.tcl file in the component editor, saving it, and destroying all of your efforts. Presumably, setting the EDITABLE parameter to FALSE would prevent the component editor from saving its changes to the xxxx_hw.tcl but in obseervation (with quartus 13.0) this protection does not exist and the component editor does write on top of the file including setting the EDITABLE parameter back to true.

The ip-generate apparently returns success (i.e. zero) status code sometimes when a java exception is thrown, and not caught

Issue: The ip-generate seems to fail routinely with a java null pointer exception; for example, when some of the component IP are not found on the search path. However, it appears that sometimes ip-generate returns successful status (i.e. zero) when this happens which causes our build system to checkpoint a successful QSYS system generation when in-fact it has failed. This consequently causes our dependency checking to fail, and users are confused; they must recover only by executing a clean rebuild from source. This was observed in Quartus 13.1.

2013.12.05.10:43:03 Warning: atlantis_processor.byte_trunk.clk_byte_trunk_rx: The input clock frequency must be known or set by the parent if this is a subsystem.
2013.12.05.10:43:03 Error: atlantis_processor.byte_trunk.st_null_packet_input_0: Component st_null_packet_input 1.0 not found or could not be instantiated
2013.12.05.10:43:03 Error: atlantis_processor.byte_trunk.st_null_packet_input_1: Component st_null_packet_input 1.0 not found or could not be instantiated
2013.12.05.10:43:03 Error: atlantis_processor.byte_trunk.st_null_packet_input_2: Component st_null_packet_input 1.0 not found or could not be instantiated
2013.12.05.10:43:03 Error: atlantis_processor.byte_trunk.st_packet_discard_sink_0: Component st_packet_discard_sink 1.0 not found or could not be instantiated
2013.12.05.10:43:03 Error: atlantis_processor.byte_trunk.st_packet_discard_sink_1: Component st_packet_discard_sink 1.0 not found or could not be instantiated
2013.12.05.10:43:03 Error: atlantis_processor.byte_trunk.st_packet_discard_sink_2: Component st_packet_discard_sink 1.0 not found or could not be instantiated
2013.12.05.10:43:03 Error: atlantis_processor.byte_trunk.dma_net_tx: Component dma_mem_to_st 1.0 not found or could not be instantiated
2013.12.05.10:43:03 Error: atlantis_processor.byte_trunk.dma_net_rx: Component dma_st_to_mem 1.0 not found or could not be instantiated
2013.12.05.10:43:03 Info: atlantis_processor.ext_memory.mem_if_ddr3_emif: Auto interface leveling mode set to 'Leveling'
2013.12.05.10:43:03 Warning: atlantis_processor.ext_memory.mem_if_ddr3_emif: 'Quick' simulation modes are NOT timing accurate. Some simulation memory models may issue warnings or errors
2013.12.05.10:43:03 Warning: atlantis_processor.bittware_ddio.clk_bittware_ddio: The input clock frequency must be known or set by the parent if this is a subsystem.
2013.12.05.10:43:03 Error: atlantis_processor.ext_mem_width_discard: Component avalon_mm_width_discard 1.0 not found or could not be instantiated
2013.12.05.10:43:03 Error: atlantis_processor.cpu_core.exp_irq/byte_trunk.dma_tx_irq: Missing connection end (try "Remove Dangling Connections")
2013.12.05.10:43:03 Error: atlantis_processor.cpu_core.exp_irq/byte_trunk.dma_rx_irq: Missing connection end (try "Remove Dangling Connections")
2013.12.05.10:43:04 Info: atlantis_processor: Generating atlantis_processor "atlantis_processor" for QUARTUS_SYNTH
2013.12.05.10:43:05 Info: pipeline_bridge_swap_transform: After transform: 7 modules, 26 connections
2013.12.05.10:43:05 Info: No custom instruction connections, skipping transform
Exception in thread "main" java.lang.NullPointerException
        at com.altera.sopcmodel.transforms.avalon.Domain.getSymmetryCheckerForPoint(Domain.java:308)
        at com.altera.sopcmodel.transforms.avalon.Domain.isSymmetric(Domain.java:284)
        at com.altera.sopcmodel.transforms.avalon.InitialInterconnectTransform.checkValidDomain(InitialInterconnectTransform.java:108)
        at com.altera.sopcmodel.transforms.avalon.InitialInterconnectTransform.doExecute(InitialInterconnectTransform.java:83)
        at com.altera.sopcmodel.transforms.SopcTransformStep.execute(SopcTransformStep.java:66)
        at com.altera.sopcmodel.transforms.SopcTransformList.doExecute(SopcTransformList.java:112)
        at com.altera.sopcmodel.transforms.SopcTransformStep.execute(SopcTransformStep.java:66)
        at com.altera.sopcmodel.transforms.mm.MMTransform.doExecute(MMTransform.java:112)
        at com.altera.sopcmodel.transforms.SopcTransformStep.execute(SopcTransformStep.java:66)
        at com.altera.sopcmodel.transforms.SopcTransformList.doExecute(SopcTransformList.java:112)
        at com.altera.sopcmodel.transforms.SopcTransformStep.execute(SopcTransformStep.java:66)
        at com.altera.sopcmodel.transforms.avalon.AvalonTransform.doExecute(AvalonTransform.java:48)
        at com.altera.sopcmodel.transforms.SopcTransformStep.execute(SopcTransformStep.java:66)
        at com.altera.sopcmodel.ensemble.EnsembleUtils.doTransform(EnsembleUtils.java:1332)
        at com.altera.sopc.generator.EnsembleGenerationFileSet2.attemptTransform(EnsembleGenerationFileSet2.java:90)
        at com.altera.sopc.generator.EnsembleGenerationFileSet2.generate(EnsembleGenerationFileSet2.java:51)
        at com.altera.sopc.generator.FileSet2.generate(FileSet2.java:134)
        at com.altera.sopc.generator.Sellafield.generate(Sellafield.java:381)
        at com.altera.sopcmodel.sbtools.sbgenerate.SbGenerate.act(SbGenerate.java:622)
        at com.altera.utilities.AltCmdLineToolBase.runTheTool(AltCmdLineToolBase.java:640)
        at com.altera.sopcmodel.sbtools.sbgenerate.SbGenerate.main(SbGenerate.java:1106)
mv atlantis_processor_ip_gen_failed.log atlantis_processor_ipgen.log

Unavoidable design unit collisions

Issue: Sometime third-party encrypted IP is packaged in a way that results in design unit collisions. Typically this must be worked around by compiling into separate libraries. When using QSys components in a system are compiled into the same library, causing errors: Error (10430): VHDL Primary Unit Declaration error at $(file): primary unit "$entity" already exists in library $qsys_system

Workaround: None known. Don't use QSys.

Multiplication distributes incorrectly in parametrized port width arithmetic

(Version: Quartus 13.1)

Consider the following parametrized port declaration:

module bug_example
  #( parameter TX_BUS_WIDTH    = 3
   , parameter RX_BUS_WIDTH    = 4
   , parameter NUMBER_OF_BUSES = 2
   )
   ( input wire [((TX_BUS_WIDTH + RX_BUS_WIDTH)*NUMBER_OF_BUSES) - 1  : 0] bus_bits
   );
endmodule

When QSys analyzes this source it determines that bus_bits has a width of TX_BUS_WIDTH + RX_BUS_WIDTH*NUMBER_OF_BUSES and indeed generates a port of width 11 = 3 + 4*2 instead of (3 + 4)*2 = 14.

Workaround: The addition must be done with another parameter, e.g.

parameter SUM_OF_WIDTHS = TX_BUS_WIDTH + RX_BUS_WIDTH

Unfortunately QSys also fails to handle ports sized by localparams so this parameter cannot be concealed within the module.

Nios II Issues Using Qsys

Using Nios II Processor for HardCopy designs 

Issue: Using Nios II Processor for HardCopy designs results compilation error in Quartus II. You may encounter similar error message in Quartus II: "Error: <name> cannot use Memory Initialization File in a HardCopy device in a non-ROM operation mode"

  Workaround: There is no workaround in Qsys. If you need to use HardCopy in your design, use SOPC Builder.

Nios Generation Fails on Ubuntu

Issue: NIOS generation fails using Quartus 11.0 on Ubuntu 11.04. This is caused by a missing locale.

  Fix: sudo locale-gen en_US  

Nios BSP and Projects fail to make on Win7

Issue: NIOS make files fail to run correctly under Windows 7 via Eclipse or command line. This affects the generation of BSP's and compilation of regular projects. The problem seems to be with file/directory permissions under the cygwin environment.

  Fix: Run Eclipse or the command prompt as administrator. (Right click to get context menu, select "Run as administrator".)


© 2010 Altera Corporation. The material in this wiki page or document is provided AS-IS and is not
supported by Altera Corporation. Use the material in this document at your own risk; it might be, for example, objectionable,
misleading or inaccurate.

 

Personal tools