Version control for Quartus/NIOS

[Altera_Forum]

Hi Everyone, 

 There have been a number of posts asking about which files need to be put under version control for Quartus/NIOS projects. After quite a bit of experimenting we&#39;ve found a minimal set of files that does the job nicely, and hope that others may find this useful.  Our development environment includes several programmers working from different sites, so it was important that the checked-in files operate within a standard Altera installation (no modified system files), and that there be no absolute path names in the repository (so that each developer can anchor their tree wherever they want).  For Quartus/SOPC projects we store the following files:   toplevel.v The toplevel verilog file for the project (instantiates the SOPC block)  toplevel.qsf Pin assignments, timing constraints, etc  toplevel.qpf Toplevel project container (for Quartus File->OpenProject)  syscore.ptf The SOPC system description  <others>.v The rest of your verilog code, user library references, etc  The idea is that a new developer pulls the above files onto a new machine, then opens SOPC builder and does a GENERATE, then goes back to Quartus and does a BUILD. There are gobs of machine generated files that will be present in the end, but only a small number of original files need to be kept in the repository.  For NIOS system libraries you only need to check-in the following files that are created by the File->New->Other->AlteraNiosII->SystemLibrary wizard:   .cdtbuild  .cdtproject  .project  system.stf  For each Quartus build I like to keep the associated system library in a directory right next to it. This allows you to replace the absolute pathnames to the .PTF file (generated by the wizard in system.stf) with "..\quartus\syscore.ptf". Again, a new developer starts with the above files, then does an Import->ExistingProjectIntoWorkspace from the C/C++ panel of the NIOS IDE, then builds the system library. The entire library then appears automagically.  Good Luck!

[Altera_Forum]

Alan, 

 Thanks for that. I tried figuring out what was needed in the past but wasn&#39;t able to pare it down as much as this. We&#39;re about to start source-controlling our Quartus designs and this will help a lot.  Andrew

[Altera_Forum]

Hi Andrew, 

 Glad that this was helpful for you -- Thanks for writing back!  We&#39;ve actually refined the process a bit further -- not because any more files needed to be checked in, but because Quartus performs so much unnecessary touching of its QSF and PTF files that the repository needs to be protected from needless recommits after each run of Quartus.  We accomplished this by doing a &#39;make volatiles&#39; immediately after the SVN checkout. What this does is create the QSF, QPF and PTF files (that Quartus will hack) from fixed templates that are kept in the repository. I&#39;ve attached parts of the Makefiles below if you&#39;re curious.  The Makefile in the Quartus project itself is: __TOP_LEVEL_ENTITY = toplevel __USER_LIBRARIES = ../../../libs/fpga __QSF_FILES =  ../../../libs/templates/kit2s60_board.qsf  ../../../libs/templates/kit2s60_phy_pins.qsf  ../../../libs/templates/phy_timing.qsf include ../../../include/quartus.mk  Which includes the following &#39;quartus.mk&#39; fragment: # *******************************************# *                                         *# *  Generic Makefile for QUARTUS Projects  *# *                                         *# ******************************************* # This Makefile fragment assumes that the following symbols have been# defined on entry:# #  __TOP_LEVEL_ENTITY : Top hierarchy name for the project#    __USER_LIBRARIES : List of library directories for Quartus#         __QSF_FILES : Component template files for the .QSF # The Quartus GUI handles actual building, so there is nothing to do# for the usual rules.# all :; clean :; distclean :; .PHONY : all clean distclean # Create the volatile files from the repository templates.  Quartus# makes countless &#39;unnecessary&#39; changes to these files during normal# operation and it would be incorrect to update the repository each# time.# volatiles : toplevel.qsf toplevel.qpf syscore.ptf .PHONY : volatiles # The .QSF file is composed from all of the pin definition and timing# constraint files that are relevant to this project.# toplevel.qsf : $(__QSF_FILES)     @echo Making $@...     cat $(__QSF_FILES) |   sed "s:__TOP_LEVEL_ENTITY:$(__TOP_LEVEL_ENTITY):" |   sed "s:__USER_LIBRARIES:$(__USER_LIBRARIES):" > $@     cp $@ $(subst .,_,$@) # The .QPF file merely mentions the toplevel entity# toplevel.qpf : ../../../libs/templates/project.qpf     @echo Making $@...     sed "s:__TOP_LEVEL_ENTITY:$(__TOP_LEVEL_ENTITY):" < $< > $@     cp $@ $(subst .,_,$@) # The .PTF (SOPC) file is simply renamed to protect the repository from# spurious checkins.# syscore.ptf : syscore_ptf     @echo Making $@...     cp $< $@  And the checked in as &#39;kit2s60_board.qsf&#39; begins with #  **********************************************#  *                                            *#  *  Altera Stratix-II RoHS Development Board  *#  *   Top-Level Pin and Project Assignments    *#  *                                            *#  **********************************************# set_global_assignment -name TOP_LEVEL_ENTITY __TOP_LEVEL_ENTITY set_global_assignment -name USER_LIBRARIES "__USER_LIBRARIES" .... ....  Note that each of the volatile files that are produced is accompanied by an original copy with the &#39;.&#39; in the filename replaced with &#39;_&#39;. This allows you to check later on what Quartus has done to those files, just in case some of its changes really should make their way back into the repository.  Good Luck!  -alan

[Altera_Forum]

We haven&#39;t been checking in the QPF files; they seem to frequently contain absolute paths which don&#39;t resolve once checked out on other users&#39; machines. Also, because of this, they are frequently "modified" just by opening them. 

 If there&#39;s no QPF file, you just open the QSF file instead and it walks you through the New Project Wizard, and al the settings (for us, it seems) are automagically set right.  In Subversion, we&#39;ve put the *.qpf pattern (and a lot of others) in the svn:ignore property of the Quartus project directory.