Automating Timestamp Updates at Build Time

In the past, I've used a simple makefile to update the revision register value to the current system time using a simple sed command as follows:

buildStamp=$(shell date +%m%d%y%H)
sed 's/ABCDEF01/$(buildStamp)/' ../ip/common/buildver_pkg.vhd > $(localTemp)/buildver_pkg.vhd

This works well when we're using a strictly command line build flow. I typically have the make file copy all of the source to a timestamped sub-directory and make this update at the time of the copy. This preserves the pedigree of the build and allows me to rerun builds from that directory without updating the revision register every time.

However, a problem arises when the Quartus II GUI is used because the revision register won't be updated. The following is one method for making the GUI update the revision register.

Add a script like this:

##############################################################################################
#
# This script copies the buildver_pkg.vhd file to the local build directory, and updates the
# placeholder string to the current system time.
#
##############################################################################################
proc copyfile { args } {
set timestamp [clock format [clock seconds] -format {%y%m%d%H}]
# Year 0-99, 7 bits
# Month 1-12, 4 bits
# Day 1-31, 5 bits
# Hour 0-23, 5 bits
set ifp [open "../ip/common/buildver_pkg.vhd" r]
set ofp [open "buildver_pkg.vhd" w]
while { [gets $ifp line] >= 0 } {
regsub -all "ABCDEF01" $line $timestamp line
puts $ofp $line
}
close $ifp
close $ofp
}
copyfile

Now, add the following line to the QSF file:

## Run script to copy buildver_pkg.vhd file and update revision register
set_global_assignment -name PRE_FLOW_SCRIPT_FILE "quartus_sh:update_build_stamp.tcl"

Now when the design is built using the build flows in the GUI, this script will be executed first and will update the revision register with the current system time.

This does not allow for subsequent builds from the makefile-generated-subdirectory area without modifying the revision register, though. I suppose we could implement an additional, less automated major revision register that is not automagically updated by a script in the GUI... but now we're circling back.