Quartus Prime 16.1 crashes at very start of Assembler phase with NO ERROR MESSAGE

[Altera_Forum]

My project (GHRD derivative with custom IP and EMIF blocks) gets through the first phases of compilation fine, but about 10 seconds into the Assembler phase (just enough time to output the first 3 lines of status text to the messages window) the "Sorry" dialogue window pops us so I can report the crash to Intel. 

 I get absolutely no useful input as to:  a.) what just happened (I get the software crashed, but give me some breadcrumbs somewhere I can follow!) b.) searchable warning or error message/number c.) nothing logged in reports showing any issue that might explain the crash, or what leads up to it  Anybody seen something similar, and willing to share your work-around or solution? Any ideas where I might find some clues?  Thanks,  -VJR

[Altera_Forum]

Can you run the Assembler standalone from the Processing menu without a crash? If it keeps happening, I'd just reinstall Quartus.

[Altera_Forum]

Running Assembler alone has the same result. 

 My Quartus install works fine with my other projects... even on halves of my current project. Really seems like something in this project codebase is making Quartus unhappy.  -VJR

[Altera_Forum]

run quartus assembler binary from terminal . the command is as follow: 

  quartus_asm <your_project_name>  it should give you what you need. but in general it is error messages related to quartus cpp . I faced this kind of problems when I missed with the pll generated hdl.

[Altera_Forum]

Thanks kais! :) 

 This does seem to point to my problem... at least I get some error output that might hint at the problem. From the cryptic messages it does seem to be unhappy about something in a PLL somewhere in the design.  Cheers,  -VJR

[Altera_Forum]

Just so this is documented somewhere... I've worked around the problem. 

 I was trying to integrate an EMIF block into my GHRD-based project. Since my previous incarnation of the GHRD project had a PLL generating my useful clocks from the base input 100MHz signal, I wanted the new EMIF to generate those clocks so there would be a firm relationship between EMIF clock domain and my project base clocks. So, in the EMIF settings in Qsys I selected the checkbox for "Specify additional core clocks based on existing PLL" and put in the necessary parameters for the 2 clock signals I wanted to generate in addition to the EMIF user clock output. That is when the problems started. Everything seems to compile just fine... but the Assembler dies seconds into its routine, and the only way to get any insight as to why is to run the assembler from the command line. At that point I see a whole mess of red text, much of which seems to be complaining about PLL settings.  This is where it gets VERY BUGGY. Going back into Qsys I unchecked the "Specify additional core clocks..." box and the clock parameters I entered disappeared. However, those settings were still getting applied to my project. There is a hard bug in the Quartus software that causes the tool to ignore that checkbox. The software is still using the (now hidden) settings I entered before and is still trying to generate my additional clocks! Hence, I got the feeling my design was now permanently broken. Only when I re-checked the "Specify..." box did my old settings come right back just as I had entered them a few days previous. I had to change the parameters entered and explicitly set the number of additional clocks to ZERO before I cleared that checkbox and all the parameters disappear from the window.  Now that I've cleared those hidden settings my design compiles again.  Next challenge... how to create associated clocks from the user_clk output of the EMIF since I can't use the EMIF's PLL to create associated signals.  Thanks for reading... hope this saves somebody a few days of banging their head against this frustrating $uite of $oftware.  -VJR

[Altera_Forum]

Hi VJR 

 1/ "However, those settings were still getting applied to my project" => make sure to check clear output directories checkbox in order to regenerate you IP files with the new options. 2/ I've tried to reproduce your issue. So I've generated an example design of Arria10 EMIF using quartus 16 pro and an I've added two additional clocks. The run was successful till assembling phase (which in contradiction with what you said). could you give more details about your issue and the error returned by the assembler. thanks kais

[Altera_Forum]

--- Quote Start ---  1/ "However, those settings were still getting applied to my project" => make sure to check clear output directories checkbox in order to regenerate you IP files with the new options. 2/ I've tried to reproduce your issue. So I've generated an example design of Arria10 EMIF using quartus 16 pro and an I've added two additional clocks. The run was successful till assembling phase (which in contradiction with what you said). could you give more details about your issue and the error returned by the assembler.  --- Quote End ---    1.) Yes, this is checked.  2.) Sounds like you reproduced my issue, where the assembler crashes after an otherwise successful compilation. I see no contradiction? I had to run the assembler from the command line to get any error output at all... GUI-driven compiles give the 3 lines of initial text output to the screen before silently falling over and asking you to describe what just happened. Sounds like this is what you've done, yes? So if you run the assembler from the command line on the failing project you'll get a bunch of red text that will explain exactly what the assembler is unhappy about. I'd have to re-break my project now to get this exact output for you... but much of it seemed like it was PLL parameter checks that were failing. What text does your failing project output from this operation? I'd be happy to confirm if it is similar to what I observed.  Cheers,  -VJR