sourcing external read-only constraints files from within the QSF file

Question

According to the Quartus ii V7.2 Handbook (4-25), sourcing of other QSF files is supported with the following command in the "parent" QSF:

source <filename>.qsf

I have found that this also seems to work using "source <filename>.tcl" instead of ".qsf" but I don't know if that causes any other issues. For the record, I'm sourcing .tcl files, not .qsf files, and they are nested (sourced files source other files). OK, now on to my problem...

I want to put some constraints in external files but make them read-only so those constraints can't be modified. The parent QSF will remain write-able so it can be editted through the GUI.

Unfortunately, Quartus appears to declare that everything is read-only if any one of those sourced files are read-only, even though the parent QSF is not. This means that none of the settings can be adjusted from the GUI anymore. I am forced to leave my sourced files as write-able.

Also, a nasty side-effect of sourcing files: If there is an invalid constraint anywhere or a syntax violation, Quartus takes all of the constraints out of the sourced files and dumps them into the bottom of the parent QSF. This is really annoying. Any way to disable this annoying feature? This is just another reason I'd like to keep the sourced files read-only.

altera_forum · Answer

The problem stems from the fact that this was never meant to be the way the .qsf was used. For a quick history:

- Original it was broken into 3 ore more files, an .csf, .psf, and one or more .esfs. All of these files were meant solely to be storage files for Quartus, i.e. the user wasn't supposed to edit them. But they were ASCII, so no surprise that people started doing that. It did not work well, and users would close Quartus and sometimes have to delete their /db just to not mess things up.

- Everything finally got merged to single file, but Quartus re-ordered everything and removed comments everytime Quartus was opened.

- The re-ordering was fixed, comments can be added directly into the assignment, and Quartus plays much more nicely.

- The ability to spread assignments was added. I think this is especially useful so the user can decide how to break things up, i.e. have a pinout file, a timing file, etc.

The problem is that I just don't think the infrastructure is there to intelligently know where things are at. Meaning, if you have all pin assignments in one .qsf that gets sourced by the master, and then change/add a pin assignment in the GUI, should that go into the master or the sourced one?

Now, I'm not saying it couldn't be better(especially the one about syntax errors issue), but I think you're running into the current state. You should file some SR/s so they at least hear your complaints. I'm guessing to do this better is a pretty large re-structuring internally, but it could definitely be improved. (I love TimeQuest's SDC files and the fact you can script anything and have complete control, but the downside is that the GUI interaction is limited.)

altera_forum · Answer

Also note that I have seen designers do full Tcl scripts to build their project.  If I remember correctly, they basically removed the project and then re-built it out of their Tcl files, all using Quartus Tcl interface.  The benefit is that they have complete control over their source .tcl files, and Quartus will never modify them.  The downside is if you use the GUI to make assignments, you then need to "capture those assignments" and add them to your source Tcl files.  Perhaps you could do some sort of combination, but it's not ideal.

altera_forum · Answer

Although it would be nice if Quartus could figure out whether constraint changes from the GUI should be applied to the parent QSF or a sourced QSF, I'm content with (and in my specific set of circumstances, prefer) changes being applied to the parent QSF. What I really want is to abstract all of my HW-specific constraints (device, pin, I/O timing, etc) from the application developers, so they can't "accidentally" change them and they don't have to sift through a QSF file that has thousands of lines of constraints that they don't understand or need to maintain themselves.

Is it possible to keep the sourced files read-only while still allowing Quartus to update constraints from the GUI in the write-able parent QSF?

altera_forum · Answer

That's a good idea. I've never tried it, but it sounds like you've already found out what happens. If you can file SRs, that would be good.

Note that you can save your .qsf as another file(probably .tcl), as a backup. Naturally, that's a pain to compare them, but you can always go to View -> Utility Windows -> Tcl console, and then in the Tcl console source that file. This basically adds them back into the project, and if any had changed or were deleted, this brings them back. Of course, they will now be put into the top-level .qsf, so that's an issue, but it's good to know if you save off a copy.

Another issue is you're manually running the command. You could add a pre-flow script that runs when the developer hits the Compile button, that would basically run this script automatically. Now, most of the time this just wastes time, because it would be re-writing your settings with identical settings, but it does prevent the developers from messing things up.

altera_forum · Answer

Not familiar with this "SR" process, but I assume it is a "SW Request" of some sort? How do I do this? Can I just refer them to this thread?

Forum Discussion

sourcing external read-only constraints files from within the QSF file

6 Replies

Recent Discussions

Questa Not Accepting My License

Repeat of a Questa License Issue

Failing IO buffer

Perpetual license Quartus II doesn't allow to build Cyclone V devices anymore.

Unable to Enrol into SSLC Due to Microsoft Authentication App Issue