VHDL syntheses timestamp

I do the same thing in my projects here.

I also have constants for (an auto-incrementing) build number as well as a source code management system unique tag number.

The bad news is that this can't be done in native VHDL.

The good news is that it's trivial to do if you script your builds (i.e. you don't use an IDE (such as the ISE GUI) to build your designs).

Create a file with a package which contains the constants, e.g.

package foo is

constant underscore_underscore_date : integer := 0;

end package foo;

package body foo is end package body foo;

Modify your (probably TCL) build scripts to parse this file and call a program to patch in a new value for the constant before the file gets compiled. Any scripting language would do; I use Perl for this.

The autoincrementing build number is a little more complicated - the script will check out the file; read the value of the constant; increment it then check the file back in.

Regards, Allan

..

Here is a very simple ready made Tcl one:

Good luck,

Hans

thanks for you hint,

I have suspected something like that.

For my embedded C projects I do some similar stuff, I patch a version and date structure to the binary output after compiling. So modifying a vhdl file with the needed information would not be the problem for me. Currently I am still using the ISE GUI, but I couldn't find any option to run custom a pre-build command. I am not sure that I am experienced enough with the build process to drop the GUI since I am using some IP cores and other GUI settings for my design.

Is there any option to use still the GUI but run some customized programs at some point? Maybe be adding some lines to some tcl script somewhere?

On the other hand I would be very attractive to have more control over the vhdl build since I always have some problems determining the files which I should put under subversion revision control.

regards Arne

date structure to the=20

blem for me.

run custom a pre-build=20

the GUI since I am using=20

at some point?

e vhdl build since I always=20

ion revision control.

In the past I did something similar (a date stamp not a time stamp) to this= but I was running it manually. I wrote a matlab code and I was running it = with octave through a batch file via scheduled tasks, many times in a day. = But later on I gave up using it because following a synthesis with date sta= mp was not so good for me besides it was confusing. I went on with a manual= version and an automatic build number.=20

All levels of synthesis in ISE can be run with TCL scripts so instead of us= ing ISE GUI you can run your synthesis with a script file, there are many t= utorials for doing this.

Also in order to add a build number to your design simply you will write a = function doing file read operation from a build file, increment it and writ= e back again to that file and you will assign the return of the function (y= our build number) to your signal like :=20

signal build_no : std_logic_vector(15 downto 0) :=3D MyBuildNumberFunction;

Assume that this assignment is done in a build.vhd file, at every synthesis= build no will increase.

For completeness, I should probably point out that the other way of doing this involves getting the value of your constant from a top-level generic. Many compilers (e.g. XST) allow the values of generics to be changed from the command line.

This still needs scripting if you want it to be automated. Many IDEs will allow generic overrides through the GUI, but it is a manual process.

Regards, Allan

__DATE__ makro).

"syntheses time" within

I've needed to do this several times, and I agree with everyone else. It can't be done in native VHDL, and probably can't be done through the GUI.

For Altera, I've used Tcl to set generics in the build script. For Xilinx, I've used a Makefile to pass the result of $(date +s) as a generic on the command line. You can also use any scripting language as a part of your build process to generate a package file.

Having tried all those approaches, they're all pains in the backside, and none of them could I find a way to integrate into the GUI based flow.

nd date structure to the=20

roblem for me.

to run custom a pre-build=20

op the GUI since I am using=20

ms at some point?

the vhdl build since I always=20

rsion revision control.

is but I was running it manually. I wrote a matlab code and I was running i= t with octave through a batch file via scheduled tasks, many times in a day= . But later on I gave up using it because following a synthesis with date s= tamp was not so good for me besides it was confusing. I went on with a manu= al version and an automatic build number.=20

using ISE GUI you can run your synthesis with a script file, there are many= tutorials for doing this.

a function doing file read operation from a build file, increment it and wr= ite back again to that file and you will assign the return of the function = (your build number) to your signal like :=20

n;

is build no will increase.

I use a Perl script to update a Verilog parameter. You could do a similar = thing with VHDL. I manually run the script when I want to embed the curren= t Unix data/time value.

It's not automated, but it does the job for me.

John P

This is a good thread.

In out system, the application software would check a version number register at boot time to make sure it was running with the right FPGA design. The problem with my manually updated version register is that I always forgot to update it until after the FPGA build and test work was done. To update the version number I had to re-run the FPGA build and, of course, the testing.

Our FPGA had a PCIe interface so it must configure from an on-board flash in order to boot in time for PCIe enumeration cycles. The on-board configuration flash is readable and writeable across the PCIe bus by the Linux host. Eventually, I noticed that the Xilinx configuration bit file header contains a date and time that is automatically incremented at build time.

I tried to get the software guys to just read the bit file header and parse the date and time out of there. They could have just used those fields as a unique identifier. In the end, I could never convince them to do that.

I have actually, sent suggestions to Xilinx on this subject but I haven't heard of any enhancements to support an automatically updated version or date/time register in the code.

--------------------------------------- Posted through

If you use a version control systems, such as CVS, SVN, (and I believe also GIT) there is a way to have it automatically update a field in the file as it is checked in with the version number. You should be able to use that to make a hardware readable register with the version number in it.

-- glen

I've done this with my own makefile, but next time I'd like to try this wit h the Synplify callback function. (If you aren't using Synplify, this prob ably won't help in your case.) Synplify lets you write TCL callback functi ons, for example, one that will run right before synthesis, so you could th eoretically write a simple 3-line TCL function that would create a date sta mp even if you're using the GUI.

Vivado now allows execution of pre-synthesis TCL scripts that can be used to generate e.g. a VHDL package file containing version numbers/time stamps.

Unfortunately, AFAIK this currently (as of Vivado 2013.2) is not usable in this case, because Vivado will detect the source files have changed AFTER synthesis, hence it will always complain that your synthesis results are out-of date. This is a known bug and I was promised that would be fixed in 2013.1, which obviously it wasn't...

So I'm sticking with my scripted flow.

Greetings, Sean

Am Montag, 23. April 2012 18:28:20 UTC+2 schrieb Rob Gaddi:

It can, but the tools don't synthesize it. In VHDL you can write code that is run once at the beginning of a simulatio n. It would be rather easy for a tool vendor (compared to the other complex tasks done during synthesis) to evaluate the results of these one time pro cesses by simulation and use the results in synthesis. These one time processes could be used to read /dev/time, to compute comple x constants (sine tables, etc.) or to read look up tables from files.

I would be great if vendors implemented this. The language supports it.

Have fun,

Kolja

I am curious as to why everyone seems to think that putting timestamps in binaries is such a good idea? Whenever I inherit a design that I need to

modify then the first thing I do is recreate the original development environment to the point where I can compile and produce the original binary.

You can't do that when you stuff in timestamps.

John Eaton

--------------------------------------- Posted through

And yet the first thing I do when my programmer tells me there's a problem with the FPGA he's talking to is ask him to confirm for me that he's using the same timestamped build I think he is.

I update my binary timestamps using a TCL script; I can always disable that script if I need to force a given timestamp. But on some level, binary reproducibility is dead. All the FPGA vendors are forcing us into complicated licensing schemes, even for the free versions of the software, that pretty much guarantee that you won't be able to run a 5 year old version of the tools simply because no one will be willing to generate you a license file for it.

But hey, who ever wanted repeatability anyhow? FPGA design is only fun if you have to spend as much time playing "What stupid new thing did the tools do today?" as you do actually designing logic.

That doesn't absolutely require a timestamp. I have used a version number that I manually set, negative values for development versions and positive values for releases. Of course, this is a register to be read by an MCU so if you don't have the MCU there is no easy way to read the version number.

How was the timestamp read or verified again?

I am still running the last version I got from my paid for (ultra low end) license that expired some four years ago. I have to remember to request a new license and so far they have not had a problem with new computers and I'm currently on my third or maybe fourth one. I hope they don't crap me out at some point, but I'm not sure it would be a huge problem. As long as the HDL code works with the newer free tools it shouldn't be a problem.

I found a long time ago that it is a *lot* of work to verify that the tools give you the hardware you expect. Mostly I have to code very small modules and build up. I try to do that even when I don't need to verify tool efficiency because it also makes test benches simpler to write. I write more of them as I build up, but each one only has to test the new functionality of the combined structure. Then when I need to verify that the tool is doing a decent job, I can synthesize on the same small modules I verified and vice versa.

wrote: > I am curious as to why everyone seems to think that putting times tamps

d to

This is a version control (or lack thereof) problem. Simply use a tool suc h as Subversion, Sourcesafe, Git, etc. and you won't need to ask your first question either. The programmer should be able to provide you with his ve rsion controlled build script that links in your FPGA file into the bigger picture...after first providing you the trace file that was captured from t he system that identified the software version number in the first place.

to

The value there is that you can in theory walk up to a system, query it and then get that binary timestamp read back. The cost is that this process s hould be more work and effort (and therefore cost) then verifying version n umbers with the version control system. The big word in that sentence thou gh is 'should'. If you're working with folks who don't like (or understand ) version control, or don't like to check things in until they are 'done' a nd queue up a huge pile of unrelated changes into a check-in then it may be easier to walk up to that system after all...assuming it's accessible.

But even in that situation, the better course is to shame them into this by simply asking how did they verify that they are using your latest FPGA? H opefully that brings up a discussion on version control where they will loo k rather foolish if they choose to defend the out of control method.

There is more to this then version control, but using version control is a huge start.

Kevin Jennings

Please listen to Kevin and all the others who recommend good version contro l practices with FPGA design. Most of the best version control tools, Subve rsion, GIT, etc, are free and open now. Check in early and check in often. Don't worry about disk space. Disk drive space is essentially free now.

The original question of this thread was about how to get a timestamp or si milar unique identifier into each and every compile. A precompile tcl scri pt sounds like a good approach. It could spit out a little HDL module with the desired info so that it can be read from the fpga by a cpu.

My old company (wisely) tried to make each fpga bitfile uniquely identifiab le so that the control software could verify that it is running the right f pga at boot time. It was very difficult to remember to manually edit a bit of HDL just to insert some updated version code.

Software guys often insert the subversion revision code into their compiled software builds. That is ideal but doesn't work with FPGA's because you d on't know if your code works (meets timing, etc) and is releaseable until a fter you compile.

Pete

Or you can simply pass a generic/parameter which contains the SHA-1 or whatever in your synthesis script.

Another common approach is go generate a MIF file or similar RAM contents file containing the SHA-1/dirty/passed. Typically this RAM will act like a ROM (e.g. the write signal is never asserted within the FPGA logic)

It's also quite common to use a script to extract the SHA-1 etc. and insert it automatically.

You can still generate the SHA-1 etc. and keep track if that particular release meet timing etc. elsewhere. Or if you use the mentioned MIF approach described above you can use a vendor supplied tool to quickly update the content of the RAM after build to include the timing information.

//Petter

Disadvantages with generating the timestamp from the HDL are that you might want to make changes after synthesis, for example changes to the timing constraints or initialising block rams.

When programming the fpga in slave mode with a cpu, some people read the timestamp embedded in the .bit file, and that works well.