Okay well I'm adding another example. This example is pretty basic. It uses two TCL scripts. One is run during pre_flow and one is run during post_flow. This particular script provides a few functions:
1 - Automatically revs some revision numbers stored in a Verilog file. I then have other verilog source files that "`include" the generated source and make the values readable to my NIOS processor.
2 - Automatically updates a build timestamp (also placed in the generated Verilog file).
3 - Checks the Quartus "Smart Action" to determine if either of the above actions need to be performed. We don't want to be modifying the verilog file and forcing a recompile if truly no changes have been made to the project. This would get things out of sync in a hurry.
4 - Updates the revision at the end of the build only if the build succeeded (No need to rev if the build failed).
So the files are:
trio_revisions.tcl - Pre_flow script file
trio_revisions_next.tcl - Post_flow script file
trio_revision.txt - Contains revision number to be used for build.
trio_revisions.vh - Generated verilog include file. Contains last revision number for build.
Now as an answer to the question:
At my previous company I wrote a much more advanced script (which I no longer have) that took the ROM based approach. In that script I gathered all kinds of information (Quartus build version, timestamp, project revision, etc.). I was advantageous to use the ROM approach because of the amount of information. Basically the script just generated a MIF file.
The other big advantage to the ROM based approach is that it modifies no source code. So If the only thing that changed in the project was fitter or assembly settings, you don't have to re-synthesize. I wish I had the script but I at least wanted to point out the advantages.
Jake
Honored Contributor
