Script to auto update .MIF

Hello my first post here,

in our company we have the also the problem with correct version in FPGA without rebuilding the whole projekt and spend a lot of time.

Looking around for a solution i found this post.

The scripts are very nice. But i think a more time saving method is using a rom in the SOPC System and just updating the hex or mif file. You can read out aut the Rom with a nios or a JTAG Interface.

After you verified your fit you just modify the hex / mif then use the Update memory init. File funktion in the Quartus processing menu. If you enabled Smart Compilation you just need to restart assembling.

Currently i'm working on an autmated way similar to your tcl example to update the information in the hex file.

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

I highly appriciate your post,Rysc.

Many thanks

[url=http://pret-auto.org]pret auto[/u] (http://pret-auto.org)

[/U][/URL]

Hello Rysc,

Thanks for this, I'll work on it now.

TTFN.

NN

Here's one that I've created. Note that it's a timestamp function as well as a Virtual JTAG Interface(VJI - there's some Altera documentation on this). You don't have to use the VJI at all, and can just rip out the timestamp.v. Note that the .qsf has the line:

set_global_assignment -name PRE_FLOW_SCRIPT_FILE "quartus_sh:write_stamp.tcl"

This calls out that .tcl file, which writes out a verilog file with a timestamp in it. (I didn't go the .mif flow, as I thought this was easier. If you had a lot of information you needed to keep, then the .mif flow might be best).

The file it writes out is called timestamp.v and is then called in by Quartus.

The reason I then hooked it up to the VJI interface is that it's a very low-overhead interfae whereby the user can probe the timestamp via Tcl. Look at get_stamp.tcl, which shows how you can open a command prompt, and if you're hooked up to the device's JTAG chain, can then go and get the timestamp to see live what device is on the board. Naturally, if you have your own interface to the FPGA, you probably don't need this and can stick with the simple timestamp.v.

i have created an nios sopc component that does nearly the same as sysid

but sysid is only updated each time sopc runs.

our sopc component includes a file that has an actual timestamp in unix format like sysid does. each time quartus starts, it includes the actual timestamp and so the sw can read out the time quartus has startet.

an external tool creates the included file holding the timestamp.