Compile errors with Qsys generated verilog

[Altera_Forum]

Error (10162): Verilog HDL Object Declaration error at c5g_nios2_dram_daq_mem_if_lpddr2_emif_p0_acv_hard_io_pads.v(289): can't declare implicit net "dqs_busout" because the current value of 'default_nettype is "none" 

 I get the above error when running analysis and elaboration on a qsys generated Nios II cpu which uses LPDDR2 RAM. This also occurs when I compile the demonstration application which comes with the Cyclone V GX Starter Kit: C5G_V.1.1.0_SystemCD/Demonstrations/C5G_LPDDR2_Nios_Test  Is there a setting that I need to change? I have tried to set the `default_nettype to "wire" but that doesn't seem to have an effect.  John

[Altera_Forum]

Actually this is the error I get when I compile the C5G_LPDDR2_Nios_Test demonstration project: 

 Error: C5G_QSYS_mem_if_lpddr2_emif_p0_pin_map.tcl: Failed to find PLL reference clock  This is after converting to Quartus II 13.1 64 bit Windows 7.

[Altera_Forum]

In Qsys 13.1 I added a LPDDR2 SDRAM Controller with UniPHY. This controller has a pll_sharing conduit which must be exported according to the following warning: 

 Warning: System.mem_if_lpddr2_emif: mem_if_lpddr2_emif.pll_sharing must be exported, or connected to a matching conduit.  I don't have any pins on my C5 GX Starter Kit board. The LPDDR2 signals are all present in the 'memory' conduit which I connected to the corresponding LPDDR2 pins. Is it safe to ignore this error? I think this may have something to do with the compile error I am getting and when I look at the C5G_LPDDR2_Nios_Test top level Verilog module it doesn't have any of the pll_shared signals in the C5G_QSYS module call.

[Altera_Forum]

The bug appears to be in the qsys Verilog code generated. There is a symbol (dqs_busout) that is not defined as a wire or anything else but is used as an output for the capture_strobe_out parameter in the function call indicated in the first post of this thread. 

 I located the altera ip that seems to be used in generating the Verilog nios2:   c:/altera/13.1/ip/altera/altdq_dqs2/  Looks like the following files may be involved:  altdq_dqs2_acv_arriav_connect_to_hard_phy.sv or altdq_dqs2_acv_arriav_connect_to_hard_phy_lpddr2.sv  What do I modify to generate a 'wire dqs_busout;' declairation?

[Altera_Forum]

To build and successfully run the Eclipse gcc generated .elf test app for the C5G_LPDDR2_Nios_Test demonstration app in Quartus 13.1 I used the input CLOCK_125_p clock to directly drive the lpddr2 pll_ref_clk input. This is the only way the Nios2 generated verilog will compile to generate the .sof fpga Nios2 code. I also set the CLOCK_125_p PIN_U12 to Differential 1.2-V HSUL. Those modifications to the original demonstration project on the CD worked and the lpddr2 sdram test app ran successfully.

[Altera_Forum]

I am attaching an archive of the working C5G_LPDDR2_Nios_Test project. This is a demonstration project which comes with the Terasic Cyclone V GX Starter Kit CD (C5G_V.1.1.0_SystemCD). It was compiled in Quartus II 13.0 on the CD but initially did not compile or work with Quartus II 13.1. 

 I was able to get the demonstration application for Nios2 LPDDR2 SDRAM to work by using an Avalon-MM clock crossing bridge. However it did not work as it did with Quartus II 13.0. To get it to work, I exported the Avalon interfaces and connected them manually. The problem seems to have been that the waitrequest signal was a waitrequest_n on the LPDDR2 interface and a waitrequest (without the _n) on the Avalon-MM clock crossing bridge. By making the connections externally I was able to invert this signal to get it to work.  John