Qsys Custom Component Problem

[Altera_Forum]

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.

[Altera_Forum]

By default conduit interfaces are not exported to the top. Click the 'export as' column beside your component in the GUI and name the interface you want to shoot up to the top.

[Altera_Forum]

Actually, I had already named the conduits for the three interfaces where I want the 

signals exported to the top. The greyed-out "Click to Export" text no longer appears there. After running generation, the signals as I named them do appear on the Qsys module.

[Altera_Forum]

using QSys, sometimes changes to components do not appear on the system contents. "F5" refreshes the system and reloads latest changes. Maybe generation also refreshes it.

[Altera_Forum]

Right the changes to the top level do not take effect until you generate the system.

[Altera_Forum]

You can see the potential port changes prior to generation by using the "HDL Example" tab. You can verify that your ports are exported. 

(At least this is my experience with Qsys in 11.1)

[Altera_Forum]

I'm certian that the custiom core in question is being included in the overall FPGA build. 

I do see the ports I've configured it for in the Qsys "HDL Example" tab. I've also opened the verilog source that Qsys generates and can see the ports defined there with the appropriate bus widths. I've re-run Qsys generation after each time that anything was changed in the Qsys configuration.  When building the three of the examples that I mentioned, all of them report virtually the same device utilization for the custom core.

[Altera_Forum]

I've narrowed down the issue to a problem with Qsys. 

 After setting up SignalTap, I learned that the resulting Avalon Bus cycle is not lasting as long as expected. The custom core creates a two clock bus cycle by deasserting the waitrequest_n (high) on the second clock cycle. When viewing the Avalon bus cycle in SignalTap, it shows that chipselect and write are going inactive prior to the deassertion of the waitrequest_n control. Since the actual register writes occur one clock cycle after the deassertion of the waitrequest_n control while chipselect is still active, no register writes are occurring. Hence the registers always reads back as zero's.  When viewing the bus cycle in the Custom Component editor, it indicates that chipselect does not deassert until one clock cycle after waitrequest_n deassertion. However Qsys is not working that way in the system and interprets the signal as being a positive active waitrequest.  To get the design running, I modified the top level hdl source by inverted the waitrequest_n signal from the new core before routing it back to the Qsys module. Now the registers are accessable and the core runs.

[Altera_Forum]

According to the Avalon 2.0 spec: 

 When present, a slave port ignores all Avalon-MM signals unless chipselect is asserted. chipselect must be used in combination with read or write. The chipselect signal is not necessary; Altera does not recommend using it.  Also when you created the component you mapped your waitrequest to the type "waitrequest_n" and not "waitrequest" right?

[Altera_Forum]

Yes, read or write must be requested (and not changed either ways) independent from waitrequest, because the subtle trap I got I would like you to confirm is that they must not be deasserted before the waitrequest is granted or else it will be granted afterwards and it locks the bus!

[Altera_Forum]

That's correct. If a master de-asserts read or write in the middle of a transaction that is being extended due to waitrequest being asserted then the spec is not being followed (and if you simulate this an assertion should occur).

[Altera_Forum]

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]

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]

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]

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]

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