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

--- 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

--- 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.

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

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 ---

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

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

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

@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