Hi,I am trying to generate a DDR2 SDRAM Controller for a single 128 MB DDR2 chip. QSYS perform a good generation (6 warning wich don't concern the ddr2 Controller) but when i try to synthesis the project i have this error : Error: Output port DATAOUT of DDIO_OUT primitive "nios2_ca1_sys:nios2_sys_inst|nios2_ca1_sys_ddr2:ddr2|nios2_ca1_sys_ddr2_controller_phy:nios2_ca1_sys_ddr2_controller_phy_inst|nios2_ca1_sys_ddr2_phy:nios2_ca1_sys_ddr2_phy_inst|nios2_ca1_sys_ddr2_phy_alt_mem_phy:nios2_ca1_sys_ddr2_phy_alt_mem_phy_inst|nios2_ca1_sys_ddr2_phy_alt_mem_phy_clk_reset:clk|altddio_bidir:DDR_CLK_OUT.ddr_clk_out_p|ddio_bidir_n5h:auto_generated|ddio_outa" must drive input port I of an I/O OBUF primitive I suspect it to be a reset problem of the controller because, before this error i have those warnings : Warning: The following bidir pins have no drivers Warning: Bidir "Ddr2_Clk_P" has no driver Warning: Bidir "Ddr2_Clk_N" has no driver Warning: Output pins are stuck at VCC or GND Warning (13410): Pin "Ddr2_Cke" is stuck at GND Warning (13410): Pin "Ddr2_Cs_N" is stuck at GND Warning (13410): Pin "Ddr2_Odt" is stuck at GND In QSYS i have connected soft_reset_n and global_reset_n inputs of the ddr2 Controller to the clk_reset ouput of the Clock source (wich also drive the reset_n input of the Nios2). I am stuck with this error, have i tried many reset configurations, but i still have this error...Is it realy a reset problem? Need Help Please.
I have rebuild the project with SOPC instead of Qsys (with the same xml file for the DDR2 presets) and this error is gone.For me it's a Qsys BUG. But the problem remains......
hi,I created my first QSYS system today which I intend to implement on the Cyclone 3 development board. I'm also getting the same error when trying to compile the system in Quartus2: ...ddr_clk_out_p|ddio_bidir_n5h:auto_generated|ddio_ outa" must drive input port I of an I/O OBUF primitive and also I have exactly the same warnings as you. "in qsys i have connected soft_reset_n and global_reset_n inputs of the ddr2 controller to the clk_reset ouput of the clock source (wich also drive the reset_n input of the nios2)." I have my system configured the same way. Did you have any luck with solving the issue ? regards Saber890
I haven't find any solution yet, but using SOPC instead QSYS.Since it's a QSYS bug (i can't confirm that), the best thing to do is to contact an Altera guy. I am not working on that problem now so i don't think i 'll find a solution by my own soon. Good Luck.
I didn't work with Quart11.0.Now it still does not work with Quatus11.0 sp1... And SOPC still advice me to switch my project into QSYS at every start up...
I switched from QSYS to SOPC and the error message dissappeared.I'm now once again trying to use QSYS (with Quartus2 version 11.0sp1) and the error message is still hanging in there. After submitting a service request I got a reply saying something about toplevel signals not being declared correctly and therefore the signals not being mapped from the toplevel to the "2nd layer" (which is strange since designs using SOPC are compiling without the error message). Apparently some of the std_logic signals need to be declared as std_logic_vector(0 downto 0). I tryed making changes in my toplevel file, however, the cryptic error message still persists. I'm looking further into this and will let you know if I find a solution. regards saber890
I got exactly the same problem. I did double-check the generated source files and my own top-file and all connections are there. But when I looked in the the RTL-viewer the connections are missing and instead it is driving a '1' on ClkDDR and ClkDDR_n, but also on Odt and Cke and cs_n.I also filed an SR.
hi again,I got som feedback from SR and I now manage to compile my project without the error message. A couple of changes had to be made in the project. In the toplevel file, where I was using the example HDL found in Qsys (which is used inorder to declare an instance of the Qsys system) I changed : from: altmemddr_memory_mem_ras_n : out std_logic; altmemddr_memory_mem_cas_n : out std_logic; altmemddr_memory_mem_we_n : out std_logic; to: altmemddr_memory_mem_ras_n : out std_logic_vector(0 downto 0); altmemddr_memory_mem_cas_n : out std_logic_vector(0 downto 0); altmemddr_memory_mem_we_n : out std_logic_vector(0 downto 0); In addition, changes need to be made to the <file_name>.v file (your file will have the same name you provided to your QSYS project) which is located in the "synthesis" folder. For several signals the output and inout wire have to be declared with an [0..0] bracket: output wire [0:0] altmemddr_memory_mem_odt, inout wire [0:0] altmemddr_memory_mem_clk, inout wire [0:0] altmemddr_memory_mem_clk_n, output wire [0:0] altmemddr_memory_mem_cs_n, output wire [0:0] altmemddr_memory_mem_cke, output wire [0:0] altmemddr_memory_mem_ras_n, output wire [0:0] altmemddr_memory_mem_cas_n, output wire [0:0] altmemddr_memory_mem_we_n, regards Saber890
I got a better solution then modifying the generated file:(Quartus 11sp1) http://www.alterawiki.com/wiki/new_qsys_issues#wrong_vhdl_example_in_qsys_for_different_blocks Sorry about the stupid link, the forum does not allow to me to post links... :evil:
Thank you!!!I have replace DDr2's the std_logic_vector(0 downto 0) into std_logic, in the entity declaration generated by QSYS. End the error is gone!! Tank you again!
It is the easy way out to compile our design, but it is the Qsys Verilog generation at fault here. In Altmem-PHY clocks (and a few other signals) have always been defined as a vector (as there are multiple clocks, clock enables, chip selects and ODTs in the case of DIMM or multi-chip designs).
@mlefevre Nice it worked also for you! :)I think if the signal is defined in the toplevel of the QSYS generated code as
inout wire bus_ssram_tcm_begintransfer_n_outthe coresponding VHDL should be
bus_ssram_tcm_begintransfer_n_out : inout std_logicMay be there are some signals defined as
inout wire some_signalthen it would be
some_signal : inout std_logic_vector(0 downto 0)But here I'm not sure because I never wrote Verilog... Anyway, the SOPC Builder created also VHDL Code, so such problems where never there...