*Why* does analysis fail (err 17044) for some qsys + ddr projects?

[Altera_Forum]

Dear all, 

 tl;dr: Error (17044) - how to stop those from happening when starting a qsys/nios/ddr3 design from scratch where the qsys part is NOT the top-level entry.   I have successfully built projects using quartus/qsys, and have some experience with other vendors, but have now stumbled upon what appears to be quite an old issue.  In order to get a better grasp of a process I like to work from a blank slate, adding what I need at places where I think they are needed, with a hierarchy that I think is appropriate, rather than remove random stuff from a pre-cooked example until something breaks. It is also the (general) way I like to teach. Anyone can follow a recipe (in case of many FPGA design examples: remove packaging and microwave for 6 minutes to get the leds to blink), but it takes an understanding of how ingredients interact and how flavors combine to become a cook.  If I make a project I have to choose what to make my top level entry. If I make a qsys project *without* ddr controller I can make that whatever I like - for instance a block diagram/schematic file. This sounds natural to me.  If I add a ddr controller to this project, I suddenly get an error:  Error (17044): Illegal connection found on I/O input buffer primitive simple:inst|simple_mem_if_ddr3_emif_0:mem_if_ddr3_emif_0|simple_mem_if_ddr3_emif_0_p0:p0|simple_mem_if_ddr3_emif_0_p0_acv_hard_memphy:umemphy|simple_mem_if_ddr3_emif_0_p0_acv_hard_io_pads:uio_pads|simple_mem_if_ddr3_emif_0_p0_altdqdqs:dq_ddio[0].ubidir_dq_dqs|altdq_dqs2_acv_connect_to_hard_phy_cyclonev:altdq_dqs2_inst|strobe_in. Source IO simple:inst|simple_mem_if_ddr3_emif_0:mem_if_ddr3_emif_0|simple_mem_if_ddr3_emif_0_p0:p0|simple_mem_if_ddr3_emif_0_p0_acv_hard_memphy:umemphy|simple_mem_if_ddr3_emif_0_p0_acv_hard_io_pads:uio_pads|simple_mem_if_ddr3_emif_0_p0_altdqdqs:dq_ddio[0].ubidir_dq_dqs|altdq_dqs2_acv_connect_to_hard_phy_cyclonev:altdq_dqs2_inst|obuf_os_0 also drives out to other destination than the buffer.  This error can be gotten rid of by simply making the qsys part (.qip file) the top-level design entry. To me this is completely counter intuitive.  *What* makes the ddr 3 controller so special that it requires the qsys to be the top level design component?  Is there an obvious thing I'm missing here?  Is this a bug and an old one at that? If so, why doesn't qsys emit a warning that the resultant design must be used as the top-level design entry in order for the design to compile correctly? If it is a bug, then it has just cost me most part of a day, and I am apparently not the only one who has been bitten by it.  regards, Theo

[Altera_Forum]

--- Quote Start ---   *What* makes the ddr 3 controller so special that it requires the qsys to be the top level design component?   --- Quote End ---   This is not correct. I never use Qsys as the top-level module.    --- Quote Start ---   I like to work from a blank slate, adding what I need at places where I think they are needed, with a hierarchy that I think is appropriate   --- Quote End ---   Yep, me too. With that in mind, take a look at this DE0-nano SDRAM project and this BeMicro-CV DDR3 project. They demonstrate how you can create everything from scratch via Tcl scripts and source code.  http://www.alteraforum.com/forum/showthread.php?t=45927 (see Post#2 attachment) http://www.alteraforum.com/forum/showthread.php?t=43992 (see Post#5 attachment)  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  This is not correct. I never use Qsys as the top-level module.  --- Quote End ---    OK. In that case I would greatly appreciate your input on what I am dong wrong in the workflow pasted below. With the qsys "simple.qip" as top-level entity it works, with the schematic as top-level entity it doesn't.  (maybe I should have been clearer: it's not the actual .qsys file that I used as one of the design files - it was the generated .qip file)    --- Quote Start ---   http://www.alteraforum.com/forum/showthread.php?t=45927 (see Post#2 attachment) http://www.alteraforum.com/forum/showthread.php?t=43992 (see Post#5 attachment)   --- Quote End ---    I had actually already picked up on those earlier. Thanks a lot for sharing :-). The settings I used for the ddr3 controller actually came from the readme in one of your examples. Though my personal experience with tcl is rather limited, I'm certain that I will get the hang of that eventually - I really don't like GUI/IDE's which *hide* how/why things work and often consider such tools harmful in the long run. Having said that, I also have to deal with people who don't know how to make, diff, grep and git clone, and by using GUI tools I can at least get some basics across without having to deal with that too.  regards, Theo   ====  Below you will find a quite minimalistic work-flow that reproduces the issue. I tried to make things as minimalistic as possible, even removing debugging (shouldn't matter as it is a compile-time problem). The design works "perfectly" (with a simple program in a memory initialization file blinking leds on a bemicro cv) WITHOUT the ddr3 stuff (clicking the "use" checkbox (*) in qsys to disable it) while a block diagram/schematic is the top-level entity. WITH ddr interface compilation fails IF a block diagram/schematic is used as the top level entity. The only "external" component I used as a compromise to my "from scratch" philosophy is a pin assignment csv file, but that should be irrelevant as compilation fails early. Replacing std_logic_vector (0 downto 0) by std_logic as suggested by solution rd05232011_576 (ancient) removes some warnings, but the error remains.    new project  directory: simple_nios_plus_ddr name: simple save project  select Cyclone V:5CEFA2F23C8  tools -> qsys processors and perhipherals -> embedded processor -> NiosII gen 2 processor  Main: select "Nios II/e"  JTAG Debug: deselect "Include JTAG debug"  Vectors: reset vector memory = absolute 0x00000000  exception vector memory = absolute 0x00000020  break vector memory = absolute 0x00000020  -> finish  basic functions -> on-chip memory  total memory size: 8192 bytes  -> finish  processors and perhipherals -> perhipherals -> pio  -> finish  memory interfaces and controllers->memory interfaces with uniphy->ddr3 sdram controller with uniphy  phy settings->speed grade 8  phy settings->enable hard external memory interface = enabled  phy settings->memory clock frequency: 333.3333MHz  phy settings->PLL reference clock frequency: 50 MHz  phy settings->Rate on avalon mm intergace: full  library->MICRON MT41J64M16LA-15E  controller settings->generate power-of-2 data bus widths for qsys or sopc builder = set  diagnostics->debugging feature set: no debugging  ->finish  connect clk to nios2_gen2_0:clk, onchip_memory2_0:clk1 and pio_0:clk connect clk_reset to nios2_gen2_0:reset, onchip_memory2_0:reset1 and pio_0:reset connect data_master to onchip_memory2_0:s1 and pio_0:s1 connect instruction_master to onchip_memory2_0:s1 connect clk to mem_if_ddr3_emif_0:pll_ref_clk,mp_cmd_clk_0,mp_rfifo_clk_0 and mp_wfifo_clk_0 connect clk_reset to mem_if_ddr3_emif_0:global_reset,soft_reset,mp_cmd_reset,mp_rfifo_reset_n_0 and mp_wfifo_reset_n_0 connect data_master to mem_if_ddr3_emif_0:avl_0 connect instruction_master to mem_if_ddr3_emif_0:avl_0 set mem_if_ddr3_emif_0 avl_0 base address to 0x10000000 export mem_if_ddr3_emif_0:status -> "status" export pio_0:external_connection -> "leds" set onchip_memory2_0 base address to 0x0000000 set pio_0 base address to 0x2000  save "simple.qsys" generate hdl->VHDL (or verilog, that's not relvant)   -> finish  this mentions that a tcl script must be run after analysis but before fitting  now add simple.qip to project  assignments -> import assignments -> "bemicro_cv.csv"  file->new->block diagram/schematic file, save as "toplevel.bdf"  insert->symbol->simple.bsf (the nios system)  insert->symbol->library->primitives->pin->input (clock_input)  insert->symbol->library->primitives->pin->input (reset_input)  insert->symbol->library->primitives->pin->output (led[0..7])  etcetera... connect everything appropriately  save and set toplevel.bsf as top level entry  compilation fails during the analysis & synthesis stage:  Error (17044): Illegal connection found on I/O input buffer primitive simple:inst|simple_mem_if_ddr3_emif_0:mem_if_ddr3_emif_0|simple_mem_if_ddr3_emif_0_p0:p0|simple_mem_if_ddr3_emif_0_p0_acv_hard_memphy:umemphy|simple_mem_if_ddr3_emif_0_p0_acv_hard_io_pads:uio_pads|simple_mem_if_ddr3_emif_0_p0_altdqdqs:dq_ddio[0].ubidir_dq_dqs|altdq_dqs2_acv_connect_to_hard_phy_cyclonev:altdq_dqs2_inst|strobe_in. Source IO simple:inst|simple_mem_if_ddr3_emif_0:mem_if_ddr3_emif_0|simple_mem_if_ddr3_emif_0_p0:p0|simple_mem_if_ddr3_emif_0_p0_acv_hard_memphy:umemphy|simple_mem_if_ddr3_emif_0_p0_acv_hard_io_pads:uio_pads|simple_mem_if_ddr3_emif_0_p0_altdqdqs:dq_ddio[0].ubidir_dq_dqs|altdq_dqs2_acv_connect_to_hard_phy_cyclonev:altdq_dqs2_inst|obuf_os_0 also drives out to other destination than the buffer.  running the aforementioned tcl script (even though analysis failed) doesn't change anything.  After changing the top level entry to simple.qip (instead of toplevel.bsdf) the same project compiles (with some warnings) and the resultant .sof can be uploaded to a bemicro cv (of course with the software included as a memory initialization file as jtag debugging doesn't work because the relevant bits have been removed)     (*) there seems to be an unrelated bug in qsys where clicking the "use" checkbox next to a component again to "use" it again after having disabled it, will show the component *with* any bus/clock/reset etc connections connected, but qsys will complain that these lines are actually unconnected. This can be "solved" by clicking every connection to first disconnect, and then clicking it again to reconnect it.

[Altera_Forum]

Hello, 

 I am having this exact same problem. I have a project utilizing a Cyclone V 5CEFA2F23C8N. It has a single Micron MT41K128M16 memory. Had an average sized Qsys project put together and compiled successfully. When I would try to do the Quartus build I would get the following error.  ************************ Error (17044):  Illegal connection found on I/O input buffer primitive poc: poc|poc_mem_if_ddr3_emif_0: mem_if_ddr3_emif_0|poc_mem_if_ddr3_emif_0_p0: p0|poc_mem_if_ddr3_emif_0_p0_acv_hard_memphy: umemphy|poc_mem_if_ddr3_emif_0_p0_acv_hard_io_pads: uio_pads|poc_mem_if_ddr3_emif_0_p0_altdqdqs: dq_ddio[0].ubidir_dq_dqs|altdq_dqs2_acv_connect_to_hard_phy_cyclonev: altdq_dqs2_inst|strobe_in.   Source IO poc: poc|poc_mem_if_ddr3_emif_0: mem_if_ddr3_emif_0|poc_mem_if_ddr3_emif_0_p0: p0|poc_mem_if_ddr3_emif_0_p0_acv_hard_memphy: umemphy|poc_mem_if_ddr3_emif_0_p0_acv_hard_io_pads: uio_pads|poc_mem_if_ddr3_emif_0_p0_altdqdqs: dq_ddio[0].ubidir_dq_dqs|altdq_dqs2_acv_connect_to_hard_phy_cyclonev: altdq_dqs2_inst|obuf_os_0 also drives out to other destination than the buffer. ******************  The above is reformatted to see the instances more clearly.  I went ahead and stripped the Qsys project down to nothing more than a clock and the memory... and the top level was just the port definitions and some wires to connect from Qsys instantiation. Still the same error.  I've tried both the hard and soft controllers. still the same error... Cyclone V does not support alt_mem_phy, so I couldn't try that one...  I've compiled with 13.1, 14.0, & 14.1... Still the same error.  I've wiped the database and deleted all of the assignments... Still the same error.  Any help would be appreciated. david

[Altera_Forum]

Hi David, 

 Have you tried making the .qip the top level design entity in your project? Because that makes the thing "just work TM" in my case. I just can't figure out why the presence of a ddr controller would make this happen.  I'm starting to think this is actually a bug, and unfortunately not the only one I have encountered in the course of getting quartus to work for me. It appears there are some unspecified interactions between components of quartus where one component thinks something different about a project than another. In particular the interaction between qsys / pin planner and assignment editor seems feeble to say the least, and the only way I've been able to get *consistent* results is by editing pin assignments (excluding the ones made through the TCL script) in the pin planner, and that is a chore. If I do it any other way (importing a csv file) I usually get wrong assignments, and I've even had it that some pin assignments showed up twice in the pin planner. So far I've only used a very limited subset of functionality, and most of the cases I get things working after trial and error and by performing steps in a very specific order. This suggests that there is limited software testing at Altera. I would file bug reports, but I wouldn't know where and as there is no public bug reporting system I can't see if my bugs are known issues/features or not.  regards, Theo    --- Quote Start ---  Hello,  I am having this exact same problem. I have a project utilizing a Cyclone V 5CEFA2F23C8N. It has a single Micron MT41K128M16 memory. Had an average sized Qsys project put together and compiled successfully. When I would try to do the Quartus build I would get the following error.  ************************ Error (17044):  Illegal connection found on I/O input buffer primitive poc: poc|poc_mem_if_ddr3_emif_0: mem_if_ddr3_emif_0|poc_mem_if_ddr3_emif_0_p0: p0|poc_mem_if_ddr3_emif_0_p0_acv_hard_memphy: umemphy|poc_mem_if_ddr3_emif_0_p0_acv_hard_io_pads: uio_pads|poc_mem_if_ddr3_emif_0_p0_altdqdqs: dq_ddio[0].ubidir_dq_dqs|altdq_dqs2_acv_connect_to_hard_phy_cyclonev: altdq_dqs2_inst|strobe_in.   Source IO poc: poc|poc_mem_if_ddr3_emif_0: mem_if_ddr3_emif_0|poc_mem_if_ddr3_emif_0_p0: p0|poc_mem_if_ddr3_emif_0_p0_acv_hard_memphy: umemphy|poc_mem_if_ddr3_emif_0_p0_acv_hard_io_pads: uio_pads|poc_mem_if_ddr3_emif_0_p0_altdqdqs: dq_ddio[0].ubidir_dq_dqs|altdq_dqs2_acv_connect_to_hard_phy_cyclonev: altdq_dqs2_inst|obuf_os_0 also drives out to other destination than the buffer. ******************  The above is reformatted to see the instances more clearly.  I went ahead and stripped the Qsys project down to nothing more than a clock and the memory... and the top level was just the port definitions and some wires to connect from Qsys instantiation. Still the same error.  I've tried both the hard and soft controllers. still the same error... Cyclone V does not support alt_mem_phy, so I couldn't try that one...  I've compiled with 13.1, 14.0, & 14.1... Still the same error.  I've wiped the database and deleted all of the assignments... Still the same error.  Any help would be appreciated. david  --- Quote End ---  

[Altera_Forum]

Theo, 

 I'm pretty sure that your on target with your different components of quartus not liking each other... Also, I'm pretty sure that the particular item that they are defining differently is the diff dqs lines of the controller... I put in a SR so hopefully we'll have some resolution soon.  david

[Altera_Forum]

Hi Theo, 

 Sorry I didn't answer earlier, I somehow missed your post.  I think the key to your issue is ...   --- Quote Start ---   this mentions that a tcl script must be run after analysis but before fitting   --- Quote End ---   Could you try calling that script via the pre-flow (or was it post-flow) script as shown in the BeMicro-CV example I posted.  Alternatively, rather than clicking the "Play" button in the GUI to synthesize the design, manually go through the sequence as described somewhere in the DDR documentation (External Memory Interfaces User Guide), eg., I think you run Processing->Start->Analysis&Elaboration, then run the pin script, and then hit the play button in the GUI (or run Processing->Start->Analysis&Synthesis). I forget the details - that is why I write Tcl scripts to automate it! :)  Cheers, Dave

[Altera_Forum]

Hi David(s) ;-) 

 I don't think it should be necessary to dive into the innards to locate the "problem" - I tried that as well, but that cost me too much time tracking down obscure errors - I think the "problem" is more fundamental, lying in the "special" way top-level entities are treated.  If I create a new minimal project with just the qsys/qip and a schematic referencing the nios+ddr block, setting simple.qip as the top level entry (not yet doing anaylisis), and *then* make an identical copy of it (cp -rp test1 test2) (*), *then* change the top level entry in the copy (test2) to the schematic (topblock.bdf), and then run a diff on these two projects, I get:  johndoe@quartushost:~/quartus$ diff -r test1 test2 diff -r test1/db/test_bdf_top_level.db_info test2/db/test_bdf_top_level.db_info 3c3 < Creation_Time = Mon Mar 2 17:35:49 2015 --- > Creation_Time = Mon Mar 2 17:36:56 2015 Only in test2/db: test_bdf_top_level.quiproj.5312.rdr.flock diff -r test1/test_bdf_top_level.qsf test2/test_bdf_top_level.qsf 42c42 <set_global_assignment -name TOP_LEVEL_ENTITY simple --- > set_global_assignment -name TOP_LEVEL_ENTITY topblock Only in test1: test_bdf_top_level.qws   so essentially exactly the same contents and the ONLY difference is in the top-level entry  test1: builds correctly. test2: analysis fails with error 17044   In the reciprocal situation the same happens - analysis fails for the project where the .qip is not the top-level entity. I don't see why/how this can happen.    regards, Theo  p.s. I'll definitely look into anything that lets me get rid of inconsistencies and allows me to apply normal software development paradigms; somehow I get the feeling that a lot of the gui veneer is not primarily there to increase engineering efficiency...  (*) and yes, I found out the hard way that you shouldn't copy (or even move) quartus projects this way if they contain software as apparently *some* paths, which are probably set outside the "software" tree, reference absolute paths, rather than relative paths, so while one thinks one is editing the copy one actually ends up editing the original - very confusing

[Altera_Forum]

@Theo, 

 Did you find out the cause for the error? I get the same error which disappears when I make the .qip file as the top module,  Regards, Naman