This page is dedicated to users that would like to put version information into their Altera FPGA. On many designs, you will be required to put information into the FPGA so that other hardware Engineers, software engineers, program managers, etc…. know what version of firmware they are working with, know when the image was created, and/or know who created the image. This page will show one of the more effective ways to add version information into an Altera FPGA.
The design used for this example is a simple Stratix V design. The design was targeted towards the Stratix V GX or GS FPGA Development kit to verify the version information in actual hardware. However, this example does not require that you target the design to hardware. A user can simply go through the process used to create the FPGA version information.
This example can be leveraged to ALL Altera FPGA families.
Stratix V GX/GS FPGA Development Kit
The following qar file contains the design example: StratixV_Top_FPGA_VERSION.qar - See attached a the bottom of this article.
This design was initially created to perform some example ECO edits. The FPGA Version portion of the design was then added for this example.
u0 : component Version
port map (
clk_clk => clk1, -- clk.clk
reset_reset_n => pll_rst -- reset.reset_n
The design has a simple top level with a Qsys component call Version instantiated at the top level. The Qsys component contains a ROM and a JTAG to Avalon Master. The ROM will be used to store the version information. Qsys was used to create a quick example using the ROM and an interface to System Console via the JTAG to Avalon component for verification in actual hardware.
A user may have an internal FPGA memory map and external or internal processor access to that memory map. The version ROM can then be added to the internal FPGA memory map RTL rather than in Qsys as shown in this example.
This example uses Quartus 15.1.
Here is the Qsys design:
The memory information file, mif file, is used to initialize the memory contents when the FPGA powers up. During a compile the mif file is merged into the compile. The final assembly file, sof file, will contain the mif file used to initialize the memory contents.
The ROM in the Qsys design has the following parameters
The mif file listed in the above picture is used to initialize the memory contents.
Here is an example of a valid mif file for this ROM.
The actual mif file is here 4/4c/FPGA_VERSION.zip
Many projects prefer the following information be contained within the FPGA for tracking purposes
For this example, we will automatically create a mif file that has timestamp and Engineer ID information using a tcl script.
The tcl script is here: d/d9/Create_fpga_version_mif.tcl
The script gets the timestamp information from the system via the clock command. The timestamp information is then assigned to a variable and then indexed in the first 7 address locations of the ROM. An example Engineer named Abe is assigned as the Engineer ID.
Here is a useful link that has an example of a Quartus II tcl date and time stamp:
After a compile or set of seed compiles are run, an Engineer may decide that one is worthy for the lab testing, production testing, or something that requires version tracking. At that point the mif file can be created via the tcl script. You can use the tcl processor in Quartus to run the tcl file.
quartus_cdb -t create_fpga_version_mif.tcl
After running the above, you should now have a FPGA_VERSION.mif file with the latest timestamp information. You can now “merge” this new mif file into the ROM within the compiled database.
quartus_cdb StratixV_Top --update_mif
You can look at the *.mif_update.rpt file to make sure the mif update completed without error. Once you have confirmed that the mif file completed without error, you can generate the sof file.
Now, you have an FPGA image that has version information inside it!
The example design contains a JTAG to Avalon Master which is used for access to System Console. The design was also targeted towards a Stratix V GX/GS PCIe development kit.
After the sof file was downloaded to the Stratix V GX/GS PCIe development kit, system console was pulled up to verify the ROM contents matched the mif file that was created via the tcl script. After bringing up System console, the following commands were run to read the ROM contents sitting at address 0x0 as seen in the Qsys picture above.
set mm [ lindex [ get_service_paths master ] 0 ]
open_service master $mm
master_read_8 $mm 0x0 16
close_service master $mm
The following picture of the System Console window validates the results.