Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Qsys Custom Component Problem

I am experiencing a problem using Qsys while adding a custom component into

a design and wanted to ask if others have seen this issue. I have run three

experiments to link in a custom component using both SOPC and Qsys under

Quartus II V11.1. One of the Qsys methods still fails.

The experiments are as follows:

1) Using SOPC and adding the new core by instantiating it in the top level

HDL source. Here, I add the Avalon MM-Slave used to link the new component

to NiosII in the SOPC System and link the I/O ports provided in the System

module to the new core within the top level HDL source file. The PLL is

also instantiated at the top level providing both a fast cpu clock and a

slow peripheral clock. The slow peripheral clock is used by multiple

SOPC peripherals and the new core. With this configuration, I can

successfully access the new core's registers.

2) Using Qsys and adding the new core by including the top level HDL file when

creating the custom component. The PLL is instantiated at the top level,

but the new core is not. This version also allows for successful access

to the new core's registers.

3) Using Qsys and adding the new core by instantiating it in the top level

HDL source. This version does not work. Just like the SOPC version, the

Avalon MM-Slave is configured to export the I/O ports needed to link the new

core at the top level. The Qsys generation does correctly place these I/O

ports in the system module. The PLL is also instantiated at the top level.

When running this version, the NiosII cpu and other peripherals that use

the slower clock still work, but the new core's registers are not accessible.

I always read 0's from the core's control register. As a small experiment,

I tried disconnecting the reset to the new core in case that was a problem.

That still didn't work.

My conclusion's at this point are that either Qsys no longer allows for the

core to be instantiated from the top level, I'm still making a mistake in

how I've tried to configure the MM-Slave's ports to the top level, or

Qsys has a problem. If Qsys is intended to still allow for the capability

to instantiate custom cores at the top level, I would still like to

pursue getting this to work that way.

15 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    When I set up the custom component, the MM-Slave interface includes the signals

    writedata, readdata, address, chipselect, write, and waitrequest_n. It also

    has interfaces for the clock and reset. Under the signals tab, the waitrequest_n

    signal name was assigned to the MM-slave interface, assigned the waitrequest_n

    signaltype, and assigned as an output. When observing the behavior with SignalTap,

    waitrequest_n behaves as if it is waitrequest. I've attached a SignalTap trace

    of the failing bus cycle. Both the chipselect and write signals are truncated

    to a single clock cycle.

    If I rebuild the design after modifying the top level hdl by inverting the

    waitrequest_n signal from the instantiation of the new core before sending it

    back to the Qsys system instantiation, then the bus cycle works correctly. In

    that configuration, both chipselect and write signals have a duration of two

    clock cycles as expected since the new core deasserts waitrequest_n (high) at

    the begining of the second clock cycle.

    During this process, I have been working with my distributor's FAE. He was able

    to reproduce the same incorrect behavior on the waitrequest_n signal using a

    completely different experimental design than I have. After that, I submitted a

    Service Request to Altera and am awaiting their response.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Perhaps the GUI isn't poking the right value into the .tcl file for your component. If you open up the .tcl file for it and search for that waitrequest_n signal it should have "waitrequest_n" listed beside it. If that's not the case manually edit that line so that the right signal type is present which should remove the need to hack the generated HDL.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    The *.tcl file created for the custom component does list the waitrequest_n

    signal type. I suspect the problem may be beyond that point during generation

    of the Qsys module.

    The reponse I received from my Service Request is that this potential bug is

    being passed to the Qsys engineering team for investigation.

    For now, this issue is not holding up any product development for me. This was

    mainly an exersice to practice with a development board, practice with Qsys, and

    prove the new core's operation in a system. To continue, I can either use

    my experiment option# 2 or the waitrequest_n signal inversion in option# 3.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    A fourth option would be to use waitrequest and invert it within your logic that way you don't need to hack up the generated HDL. The Qsys fabric internally uses waitrequest so I'm guessing the bug you are seeing is the inverter in the translation block is missing.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Today I confimed that Quartus II V12.0 corrects this problem in Qsys with incorrect polarity being used for waitrequest_n.