Quartus II good practices questions

[Altera_Forum]

Question on how to make my designs best readable if someone else has to take a look. 

I am testing code on a starter board, Terasic DE1. I am also working on a PCB design that will use a smaller FPGA with 144 pins so I can solder it myself. Do I make different fitter files I can switch within the same Quartus II project, or should I make a second project file /folder that calls up the same code files. Any advice please. Remeber I am working on a fun/hobby/self educate project with no deadline.

[Altera_Forum]

I always have one folder or folders (containing a collection of previously used and debugged modules) containing the code and as many projects for variants or for debugging modules as I need. If designed carefully a lot of VHDL can be re-usable. Don't know if this is standard or good practice as I am self taught.

[Altera_Forum]

It sounds like the fundamental question is how to handle two designs that are nearly the same without treating them as two completely independent designs. 

 Consider using the revisions feature available at "Project --> Revisions". Both designs would be in the same Quartus project. The feature uses a separate .qsf file for each revision. It is up to the user to keep all the settings matching that need to match between the revisions. Create an initial revision that has all the settings that are common between the two designs. Create a new revision from the original and make the needed changes in the second revision. Both revisions can use the same source files (and they can have differences in their two sets of source files). It sounds like for your case you might want to have all the settings be the same in the two revisions except for the device selection and pin locations. When you compile with a particular revision selected, you will get report and programming files with the same base filename as the .qsf filename (the revision name), so you will have two sets of reports and programming files in the same project directory.  With a completely separate Quartus project for each design (not using the revisions feature), you can put all the settings that are identical between the two designs (including the .qsf settings that list the source files being used) in a Tcl file and have the .qsf file for each design source the Tcl file. Create the project for one of the designs. Move all the .qsf lines that should be identical between the two designs into a .tcl file, replacing them with "source my_shared_settings.tcl" in the .qsf file. Make a copy of the Quartus project for the second design. Work with both Quartus projects normally for managing settings stored directly in the .qsf files. Using the same .tcl file for both projects ensures that the settings in that file will be identical between designs. There are some limitations to this approach--you might not get what you'd expect if you use the GUI to change a setting that is stored in the Tcl file.  Another solution is to use a Tcl file to create all the settings for the two designs with the Tcl file managing what is the same or different between designs.

[Altera_Forum]

--- Quote Start ---  I always have one folder or folders (containing a collection of previously used and debugged modules) containing the code and as many projects for variants or for debugging modules as I need. If designed carefully a lot of VHDL can be re-usable. Don't know if this is standard or good practice as I am self taught.  --- Quote End ---    This is much like what I do.  I have one folder that contains my source code and simulation files, usually called ./project/src/ I have folders underneath .src/ that control the revisions of my codeset (e.g. src/v0_10, src/c0_20, src/1_00 with 0_ numbers being pre-release and 1_ styled number being post release) I have another folder that contains the build files for whatever fpga technology I am using, usually called ./project/par. That folder also contains individual folders that track the version numbers in the /src/ folders.   Both Altera and others have ways to make revisions, which Brad just wrote about and those are fine, too. I do not use them only because I have my own system independent of the big A and the big X.  BR