Working with Multiple QSF files

[Altera_Forum]

I'm developing a board suppport package that I can use for multiple applications that are built for the same part. I currently have two applications that use common top-level RTL, but they have individual Quartus files (qpf, qsf, sdc,...). The pin mappings, constraints, assignments, and even RTL are still in flux for the board support portion of the design, which means that I'm copying project settings between the two projects regularly, and it stinks.  

 Of course, a good design practice would to put common settings and constraints into separate qsf/sdc/tcl files that can be pulled in by each of the application projects. I moved some assignments that were common to application1.qsf and appplication2.qsf into a new file called common.qsf. I followed altera's example (http://quartushelp.altera.com/13.0/mergedprojects/reference/glossary/def_qsf.htm) (source common.qsf from application1.qsf), and it's functional, but three unfortunate things happen. For one, all the assignments from common1.qsf get copied into application1.qsf during sythesis, which is the exact opposite of what altera's documentation (http://quartushelp.altera.com/13.0/mergedprojects/reference/glossary/def_qsf.htm) (same link) says will happen. Even more, if all the assignments aren't already in application1.qsf, then Quartus gives me an error message box saying the settings file has been modified by hand, and it has an error. Finally, if I remove one of the assignments from common.qsf, it is NOT removed from application1.qsf as a consequence of it copying all the assignments to application1.qsf.   What gives? I'm building for an Arria V using Quartus 13.1 if that matters. I'm looking at a Cyclone III Development Board example from Altera, and it uses multiple qsf files, but the data from each one appears to be copied into the main qsf....which again appears to contradict Altera's documentation.

[Altera_Forum]

I work with users that do the same thing and have seen it work. (The one I can think of that does it a lot, they called it a different extension, but didn't think that would matter). Anyway, what you're seeing shouldn't occur and contradicts what's supposed to happen. If no one provides a solution here, please file an SR so it can be fixed.

[Altera_Forum]

The issue appears to be with using specific commands in the pre-flow script in addition to multiple QSF files. I tried modifying the a5gt_golden_top design for FPGA2 provided in the Arria V GT Development Kit SDK. If I move some of the QSF assignments to a separate file and add "source separate_file.qsf" to a5gt_golden_top.qsf, everything works as billed in the documentation. cool. However, if I add a pre-flow script that removes all source code, I get the error message saying that the QSF file has errors. I'll illustrate. 

 Working pre-flow script: project_open a5gt_golden_top.qpf set_global_assignment -name VERILOG_FILE a5gt_golden_top.v export_assignments project_close  Failing pre-flow script: project_open a5gt_golden_top.qpf remove_all_global_assignments -name VERILOG_FILE set_global_assignment -name VERILOG_FILE a5gt_golden_top.v export_assignments project_close  I've tried a variety of permutations with the code in this script, and the only thing that matters is if I remove all source code. I'm feeling like this is a bug in the toolchain, but I'm far from an expert on Quartus.

[Altera_Forum]

Strange. Definitely file a Service Request, as I don't think that is correct behavior. 

I assume that particular verilog file isn't in the added supplemental .qsf? Also note that for the pre-flow scripts that I don't use export_assignments. I'm not saying that's a problem, nor that it will fix it, as I don't remember using a pre-flow script in conjunction with secondary .qsf files, but maybe one more thing to try. But yes, sounds like a bug. Bet you banged your head on the table a few times having to debug that.

[Altera_Forum]

Rysc, thanks for your help. I've tried leaving out each of the pre-flow script commands (inlcuding export_assignments, project_close, and both) to no avail. I'm putting in a service request now. I tried correcting a spelling mistake on my original question a couple days ago, and now it doesn't show up. I'd like to reference this thread in my service request, but it won't make much sense without the original question. Can you or a moderator make my original message appear?

[Altera_Forum]

Sorry, I don't know how to do that, but I set up the forum to email on new posts, so I dug up the original email with the starting post: 

 I'm developing a board suppport package that I can use for multiple applications that are built for the same part. I currently have two applications that use common top-level RTL, but they have individual Quartus files (qpf, qsf, sdc,...). The pin mappings, constraints, assignments, and even RTL are still in flux for the board support portion of the design, which means that I'm copying project settings between the two projects regularly, and it stinks.   Of course, a good design practice would to put common settings and constraints into separate qsf/sdc/tcl files that can be pulled in by each of the application projects. I moved some assignments that were common to application1.qsf and appplication2.qsf into a new file called common.qsf. I followed altera's example (http://quartushelp.altera.com/13.0/mergedprojects/reference/glossary/def_qsf.htm) (souce common.qsf from application1.qsf), and it's functional, but three unfortunate things happen. For one, all the assignments from common1.qsf get copied into application1.qsf during sythesis, which is the exact opposite of what altera's documentation (http://quartushelp.altera.com/13.0/mergedprojects/reference/glossary/def_qsf.htm) (same link) says will happen. Even more, if all the assignments aren't already in application1.qsf, then Quartus gives me an error message box saying the settings file has been modified by hand, and it has an error. Finally, if I remove one of the assignments from common.qsf, it is NOT removed from application1.qsf as a consequence of it copying all the assignments to application1.qsf.   What gives? I'm building for an Arria V using Quartus 13.1 if that matters. I'm looking at a Cyclone III Development Board example from Altera, and it uses multiple qsf files, but the data from each one appears to be copied into the main qsf....which again appears to contradict Altera's documentation.

[Altera_Forum]

Just to follow up, I opened a service request with Altera, and they provided a solution that works. Instead of using the standard <source supplemental.qsf> in your top-level QSF file, add the following statement to your top-level QSF: 

 set_global_assignment -name SOURCE_TCL_SCRIPT_FILE supplemental.qsf  Also, be sure to close the project in Quartus, add this line to your QSF, then reopen the project.

[Altera_Forum]

I've been filling service requests regarding this issue for the last 2.5 years. 

Meanwhile, a quick workaround is to make *.qsf files read-only, so that Quartus GUI wouldn't modify them. If the same project is build from command like (either TCL, shell, or other scripts), that issue doesn't happen.  Thanks, Evgeni

[Altera_Forum]

Hello all,  

 Please, does anyone know how I can change the width or the depth of the qip RAM using qsf files (TCL commands)?  I want to change them without the need to open the ip core.    Appreciate any help